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ПРЕДИСЛОВИЕ РЕДАКТОРА ПЕРЕВОДА 


На протяжении трех последних десятилетий вычислительная техника все 
стремительнее и шире охватывает различные сферы человеческой деятель¬ 
ности. Эта тенденция наблюдается и в настоящее время. Существует много 
причин столь бурного развития вычислительной техники, однако домини¬ 
рующая роль принадлежит достижениям в области технологии производст¬ 
ва электронных схем: широкое распространение больших, а в настоящее 
время и сверхбольших интегральных схем, массовое производство семейств 
микропроцессоров. Значительное увеличение производительности упомяну¬ 
тых схем, являющихся аппаратной основой ЭВМ, и существенное снижение 
их стоимости, обусловленные не только техническим прогрессом, но и массо¬ 
вым характером их производства, явились предпосылкой для пересмотра 
принципов организации ЭВМ, базирующихся главным образом на традици¬ 
онной модели вычислительной машины фон Неймана, разработанной еще 
в 40-х годах.' 

Автор предлагаемой читателю книги определяет необходимость указан¬ 
ного пересмотра основ организации ЭВМ наличием так называемого семан¬ 
тического разрыва между возможностями аппаратных средств современных 
ЭВМ, с одной стороны, и программного обеспечения этих машин, с другой. 
Рабочие характеристики аппаратных средств и сейчас, как правило, обус¬ 
ловливаются основополагающими принципами модели фон Неймана, тогда 
как параметры программного обеспечения во многом зависят от языков про¬ 
граммирования, а следовательно, и от класса задач, подлежащих решению. 
Определяя проблемы, стоящие перед разработчиком архитектуры современ¬ 
ной ЭВМ, прежде всего как проблемы организации интерфейса между тре¬ 
бованиями, предъявляемыми к программному обеспечению, и возможностями,, 
предоставляемыми современными аппаратными средствами, автор проводит 
разносторонний и, как правило, глубокий сравнительный анализ принципов 
организации целого ряда вычислительных систем, появившихся в последние 
годы и являющихся отступлением, а иногда и отказом от традиционной мо¬ 
дели машины фон Неймана. Читатель найдет много интересного материала, 
посвященного описанию не только ЭВМ нетрадиционной архитектуры 
(SWARD, іАРХ 432), ориентированных на максимальное согласование с тре¬ 
бованиями новых языков программирования (Паскаль, Ада), быстро завое¬ 
вывающих умы и сердца программистов во всем мире, но и так называемых 
машин баз данных (RAP, CASSM) и потоков данных (модель Массачусет¬ 
ского технологического института). На протяжении всей книги красной 
нитью проходят два важных положения современного подхода к проблемам 
организации вычислительного процесса: 1) предметом вычислений следует 
считать не данные, хранимые в ячейках памяти, а разнообразные классы 
абстрактных объектов, корректная манипуляция которыми и является 
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целью организации вычислений; 2) основные характеристики вычислительной 
системы должны оцениваться не скоростью выполнения отдельных элемен¬ 
тарных операций, а машинным временем и объемом памяти, необходимыми 
для выполнения операций над абстрактными объектами в пределах строго 
определенных контекстов программ. 

Книга представляет собой одну из первых попыток всестороннего и си¬ 
стематизированного исследования проблем современных ЭВМ с позиций из¬ 
вестного противоречия между их аппаратными средствами и программным 
обеспечением. Критика традиционных решений сопровождается анализом 
современных достижений на пути совершенствования архитектуры вычисли¬ 
тельных систем. Все это делает данную книгу крайне полезной для лиц, спе¬ 
циализирующихся в области разработки средств вычислительной техники, 
роль которой в окружающем нас мире трудно переоценить. 

Перевод книги выполнен канд. техн. наук В. И. Гуревичем (гл. 1—12, 17), 
канд. физ.-мат. наук Ю. Н. Жежелем (гл. 13—16, 18—21) и М. Л. Миримо- 
вым (гл. 22—24). 


В. К. Потоцкий 
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За три года, прошедших со времени первого издания данной книги, достиг¬ 
нуты значительные успехи по совершенствованию архитектуры вычислитель¬ 
ных машин. Этому способствовал целый ряд факторов, в том числе появле¬ 
ние промышленно выпускаемых сверхбольших схем, возобновление интереса 
к разработке языков программирования и признание широким кругом спе¬ 
циалистов в области вычислительной техники тех ее основных принципов и 
проблем, которым посвящено первое издание настоящей книги. (Одной из 
таких проблем является разработка программного обеспечения вычисли¬ 
тельной системы путем совершенствования архитектуры ее аппаратных 
средств.) Упомянутые факторы нашли свое воплощение в таких вычисли¬ 
тельных системах, как іАРХ 432 фирмы Intel, система 38 фирмы IBM, а так¬ 
же новый вариант машины SWARD (первоначальный вариант этой машины 
описан в первом издании книги). 

Побудительными мотивами к выпуску второго издания послужили не 
только разработка упомянутых систем, но и появление таких новых понятий 
в области вычислительной техники, как машины потоков данных и машины 
баз данных. Все это позволило расширить круг вопросов, освещенных в пер¬ 
вом издании, а также более детально проанализировать их с учетом личного 
опыта автора, накопленного в процессе реализации аппаратных средств и 
программного обеспечения системы. 

По структуре второе издание мало отличается от первого. Часть I 
(гл. 1—4) существенно переработана, содержит теперь больше количествен¬ 
ных оценок анализируемых вопросов и, как хотелось бы надеяться, является 
более аргументированной. Так, в гл. 4 в качестве примеров приводятся све¬ 
дения, заимствованные из документации систем 68000 фирмы Motorola ■ 
38 фирмы IBM. Примеры, используемые в первом издании в качестве пред¬ 
мета анализа в частях II, III и IV, сохранены и во втором издании, причем 
удалось устранить ряд ошибок и неточностей, допущенных в предыдущем 
издании. Часть V, посвященная принципам системы SWARD, полностью пере¬ 
работана, благодаря чему отражает текущее состояние достижений в про¬ 
ектировании архитектуры вычислительных систем этого типа. Часть VI яв¬ 
ляется новой и содержит описание системы іАРХ 432 фирмы Intel, т. е. си¬ 
стемы, во многом изменившей существующие представления об архитектуре 
микропроцессоров. Часть VII представляет собой расширенный вариант из¬ 
ложения материала первого издания книги, посвященного машинам баз дан¬ 
ных. Новым по сравнению с первым изданием является здесь описание ма¬ 
шин потоков данных. Завершающая книгу часть VIII включает некоторые 
общие сведения об особенностях разработки архитектуры вычислительной 
системы. 

Я хотел бы выразить благодарность Джорджу Коксу, Джастину Ретне- 
ру и Кену Оперлю — сотрудникам фирмы Intel, а также Дейву Дитцелу 
(Bell Laboratories), которые внесли определенный вклад в подготовку вто¬ 
рого издания книги. 

Санта-Клара, Калифорния Гленфорд Дж. Майерс 

октябрь 1981 
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Начиная с 50-х годов мы являемся свидетелями многих достижений в со¬ 
здании и совершенствовании вычислительных систем. Громадные успехи по¬ 
лучены в области программного обеспечения ЭВМ, благодаря чему в настоя¬ 
щее время стали эффективнее средства программного обеспечения, 
методология проектирования и языки программирования. Наборы приклад¬ 
ных программ отличаются более сложной структурой и более широкими 
возможностями. Появились алгоритмы, построенные на новых принципах. 
Изменились приемы и средства программирования, так что стали ясными 
принципы построения таких программ, как компиляторы и программы опе¬ 
рационной системы Большой прогресс достигнут также в области аппарат¬ 
ных средств ЭВМ: на несколько порядков увеличились быстродействие и 
плотность монтажа электронных схем; разработаны запоминающие устрой¬ 
ства на новой технологической базе; предложены более совершенные алго¬ 
ритмы функционирования аппаратных средств; широко реализуются принци¬ 
пы микропрограммирования. Однако происшедшие изменения не сопровож¬ 
дались какими-либо значительными достижениями в отношении улучшения 
аппаратно-программного интерфейса вычислительной системы — того уровня 
ее организации, который получил наименование архитектуры ЭВМ. Чтобы 
быть объективным в оценке развития вычислительной техники, следует отме¬ 
тить, что имели место некоторые и весьма существенные успехи в развитии 
архитектуры ЭВМ, однако они не привлекли к себе достаточного внимания 
специалистов и не получили адекватного воплощения в большинстве тради¬ 
ционных вычислительных систем. Подтверждением этого может служить тот 
факт, что система команд многих современных больших систем, мини- и мик¬ 
ро-ЭВМ до сих пор удивительно похожа на систему команд аналогичных 
ЭВМ, сконструированных еще в 50-е годы. 

Сходство архитектур современных и более ранних вычислительных си¬ 
стем может вызывать даже чувство удовлетворения: с одной стороны, име¬ 
ются громадные достижения в области аппаратных и программных средств 
ЭВМ, с другой — существует преемственность в архитектуре машин различ¬ 
ных поколений. Это позволяет сделать вывод, что в 40—50-х годах все прин¬ 
ципиальные изобретения в области архитектуры ЭВМ уже были сделаны, и, 
следовательно, архитектура вычислительных систем будущего не претерпит 
никаких изменений. Именно такое отношение к проблемам архитектуры 
ЭВМ побудило автора написать эту книгу. В данной работе делается попыт¬ 
ка поставить под сомнение возникшее чувство удовлетворения преемствен¬ 
ностью архитектуры машин прошлого и настоящего, показать, что архитек¬ 
туре современных ЭВМ присущ ряд серьезных проблем, а также обсудить 
новые направления совершенствования архитектуры, которые могут привес¬ 
ти к решению указанных проблем. 
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Назначение этой книги хорошо определяет и тот выбор, который при¬ 
шлось делать автору между двумя первоначальными вариантами‘-ее назва¬ 
ния. Первое название, к которому склонялся автор, — «Архитектура ЭВМ 
пятого поколения». Поколение машин предполагалось назвать пятым, пото¬ 
му что, по мнению автора, четвертое поколение вычислительных машин уже 
находилось на чертежных листах проектировщиков ЭВМ, причем эти систе¬ 
мы, безусловно, сохраняли архитектуру ранее созданных машин. Однако от 
такого названия пришлось отказаться, поскольку оно представлялось слиш¬ 
ком вызывающим и, кроме того, в определенном смысле дезинформировало 
бы читателя. Это связано с тем, что целый ряд положений, рассматриваемых 
в данной книге, присущ и некоторым ЭВМ второго поколения. Второе назва¬ 
ние из первоначально предполагаемых — «Архитектура ЭВМ второй эры» — 
было также отвергнуто, поскольку читатель мог бы легко принять термин 
«эра» за термин «поколение», поэтому у него могло создаться впечатление, 
что эта книга — исторический обзор таких вычислительных машин второго 
поколения, как IBM 1401, Burroughs 200 и других машин, построенных на ос¬ 
нове транзисторов. 

Структура данной книги такова, что все главы объединены в шесть ча¬ 
стей. В части I даются определение архитектуры вычислительной машины, 
критическая оценка архитектуры современных ЭВМ и формулировка набора 
характеристик, которыми должна обладать архитектура ЭВМ будущего. 
В частях II—V описываются отдельные вычислительные системы, воплощаю¬ 
щие в себе современные достижения в развитии архитектуры ЭВМ. Эти си¬ 
стемы иллюстрируют также реализацию ряда характеристик архитектуры, 
целесообразность которых определена в части I. В части VI анализируются 
некоторые проблемы, связанные с архитектурой ЭВМ: организация ввода- 
вывода, оптимизация, или «настройка», архитектуры конкретной вычисли¬ 
тельной системы и др. 

Книга предназначена для читателей двух категорий: ее могут использо¬ 
вать студенты, специализирующиеся в области вычислительной техники, как 
вторую часть учебного пособия по архитектуре ЭВМ. (Предполагается, что 
первая часть пособия знакомит с основами архитектуры традиционных 
ЭВМ.) Кроме того, книга представляет интерес для специалистов, так как 
расширяет существующие представления в области вычислительной техники. 
Книга рассчитана на подготовленного читателя. Он должен быть знаком 
с основами вычислительных систем, в том числе с языками программирова¬ 
ния высокого уровня, машинным языком или языком ассемблера традицион¬ 
ной ЭВМ, принципами организации и функционирования операционной си¬ 
стемы и компиляторов, а также микропрограммированием. Автор считает, 
что знание перечисленных вопросов является необходимой предпосылкой для 
разработки архитектуры ЭВМ. 

По глубокому убеждению автора, наиболее эффективный способ изуче¬ 
ния архитектуры ЭВМ оостоит в использовании описания архитектуры кон¬ 
кретной ЭВМ и мысленном компилировании программ, написанных на языке 
высокого уровня, применительно к этой системе. Именно так построены мно¬ 
гие примеры, приводимые в книге. При пользовании книгой как учебным 
пособием рекомендуется воспроизвести в уме процедуру компилирования 
небольших программ на языках ПЛ/1, КОБОЛ или ФОРТРАН, ориентиру¬ 
ясь на архитектуру каждой из рассматриваемых вычислительных систем. 

Наконец, следует отметить, что излагаемый в книге материал отобра¬ 
жает точку зрения автора, которая не обязательно совпадает с мнением 
фирмы IBM, и знакомит с направлениями дальнейшего совершенствования 
ЭВМ, выпускаемых этой фирмой. 


Январь 1978 


Гленфорд Дж. Майерс 




ЧАСТЬ I 

НЕОБХОДИМОСТЬ УСОВЕРШЕНСТВОВАНИЯ 
АРХИТЕКТУРЫ ЭВМ 


ГЛАВА 1 

ОПРЕДЕЛЕНИЕ ПОНЯТИЯ «АРХИТЕКТУРА ЭВМ» 

Поскольку термин «архитектура ЭВМ» трактуется самым раз¬ 
личным образом, необходимо точно определить, что под ним 
будет подразумеваться в данной книге. С этой целью рассмот¬ 
рим процесс проектирования вычислительной системы в целом. 

Для неспециалиста термин «архитектура» обычно ассоции¬ 
руется со строительными объектами, и действительно имеется 
много общего между таким толкованием этого термина и по¬ 
нятием «архитектура ЭВМ». Однако существует неправильное 
мнение, что архитектура зданий находит свое воплощение в их 
внешнем виде, высоте холла, размещении зеркал, интерьере. 

В действительности указанные факторы хотя и играют опре¬ 
деленную роль, но представляют лишь небольшую часть проб¬ 
лемы. Усилия архитектора в равной мере должны быть направ¬ 
лены на то, чтобы здание соответствовало своему функциональ¬ 
ному назначению, т. е. удовлетворяло требованиям, предъявляе¬ 
мым к нему лицами, эксплуатирующими здание. Это относится 
как к жилым помещениям, так и к служебным, например 
транспортным сооружениям, учреждениям связи. Здание долж¬ 
но быть удобным в эксплуатации (близость подсобных помеще¬ 
ний к основным служебным, наличие системы отопления), без¬ 
опасным (наличие системы противопожарной сигнализации, 
аварийных выходов, системы охраны персонала), надежным 
(обеспечение требуемого запаса прочности, использование ис¬ 
пытанной на практике технологии сооружения зданий). Наряду 
с этим необходимо учитывать экономические показатели и ряд 
других факторов. Таким образом, архитектор имеет дело с 
проблемами, лежащими по обе стороны границы взаимодейст¬ 
вия проектируемого сооружения с лицами, его эксплуатирую¬ 
щими, и окружающей средой. Более того, на него возлагается 
задача формального определения этих границ, т. е. контуров 
здания и всех его подсистем. Однако, когда появляются такие 
требования к проекту системы (в частности, к сооружению зда- 
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ния), как использование современной технологии, обеспечение 
удобства в эксплуатации, безопасности, надежности, приемле¬ 
мой стоимости, становится ясно, что речь идет о решении тех¬ 
нических проблем и профессии инженера. Вот почему можно 
сказать, что архитектура — это одна из форм инженерии, и чи¬ 
татель должен постоянно помнить, что решения архитектурных 



Рис. 1.1. Многоуровневая организация архитектуры 
вычислительной системы. 


$адач следует ожидать скорее от инженеров, чем от представи¬ 
телей мира искусства. 

Применительно к вычислительным системам термин «архи¬ 
тектура» может быть определен как распределение функций, 
реализуемых системой, по отдельным ее уровням и точное опре¬ 
деление границ между этими уровнями. Таким образом, если 
архитектуре системы отведен некоторый уровень, то в первую 
очередь необходимо установить, какие системные функции пол¬ 
ностью или частично выполняются компонентами системы, на¬ 
ходящимися выше и ниже заданного уровня. После решения 
этой задачи следующий шаг заключается в точном определении 
интерфейсов для рассматриваемого уровня. 

Таким образом, архитектура вычислительной системы пред¬ 
полагает многоуровневую организацию. Архитектуру вычис¬ 
лительной системы можно определить путем выявления ее отли¬ 
чий от других видов архитектуры. Так, специфическим свойст¬ 
вом архитектуры вычислительной системы является возмож¬ 
ность выделения в ней набора уровней абстракции (рис. 1.1). 
(При рассмотрении проблем, связанных с отображением неко¬ 
торой концептуальной модели, подобной изображенной на 
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рис. 1.1, может сложиться впечатление, что требуемые техниче¬ 
ские решения уже определены — в действительности это не 
так!) 

Архитектура первого уровня, называемая архитектурой систе¬ 
мы и символически помеченная цифрой 1, определяет, какие 
функции по обработке данных выполняются системой в целом, 
а какие возлагаются на «внешний мир» (пользователей, опера¬ 
торов ЭВМ, администраторов баз данных и т. п.). Система 
взаимодействует с внешним миром через два набора интерфей¬ 
сов: языки (такие, как язык оператора терминала, языки про¬ 
граммирования, языки описания и манипулирования базой дан¬ 
ных, язык оператора ЭВМ, язык управления заданиями) и си¬ 
стемные программы (прикладные программы, созданные разра¬ 
ботчиком системы, например программы-утилиты, программы 
редактирования, сортировки, восстановления и обновления ин¬ 
формации). Разработка архитектуры системы предполагает оп¬ 
ределение обеих групп этих интерфейсов. 

Интерфейсы 2, 3 и 4 разграничивают определенные уровни 
внутри программного обеспечения, хотя они в большинстве слу¬ 
чаев не имеют каких-либо общепризнанных наименований. Если 
программы, реализующие прикладные задачи, написаны на 
языках программирования, не входящих в число тех, которые 
предоставлены в распоряжение пользователя, то можно гово¬ 
рить об архитектуре уровня, назначение которого — определе¬ 
ние указанных языков. Трансляторы таких языков в свою оче¬ 
редь взаимодействуют с более низкими уровнями программного 
обеспечения, обозначенными на абстрактной модели архитек¬ 
туры как уровни 3 и 4. Уровень управления логическими ресур¬ 
сами может включать реализацию таких функций, как управле¬ 
ние базой данных, файлами, виртуальной памятью, сетевой те¬ 
леобработкой. К уровню управления физическими ресурсами 
относятся функции управления внешней и оперативной па¬ 
мятью, внутренними процессами, протекающими в системе (на¬ 
пример, процессами планирования и синхронизации), а также 
другими аппаратными средствами. Из-за отсутствия лучшего 
термина о всех трех уровнях 2—4 будем говорить как об архи¬ 
тектуре программного обеспечения. 

Уровень 5 отражает основную линию разграничения систе¬ 
мы, а именно границу между системным программным 1 ) и аппа¬ 
ратным обеспечением (термин «аппаратное обеспечение» ис¬ 
пользуется здесь для обозначения как микропрограмм, так и 
электронных логических схем). Термины «микропрограммное 
управление/микрокод/микропрограмма» не имеют стандартно¬ 
го универсального определения и часто используются непра- 


’> То есть операционной системой ЭВМ. — Прим, перев. 




ОПРЕДЕЛЕНИЕ ПОНЯТИЯ «АРХИТЕКТУРА ЭВМ» 13 


вильно. В данной книге они употребляются в традиционном 
смысле: микропрограмма — это записанная в памяти програм¬ 
ма, которая фактически управляет передачей всех символов и 
данных в физических компонентах системы, таких, как шины, 
регистры, сумматоры или процессор; другим альтернативным 
средством управления передачей сигналов и данных является 
использование последовательностных логических схем [1]. 
Итак, уровень (интерфейс) 5 позволяет представлять физиче¬ 
скую структуру системы абстрактно независимо от способа реа¬ 
лизации. Разграничение функций, выполняемых выше и ниже 
этого уровня, и определение интерфейса 5 — одна из составных 
частей процесса разработки архитектуры ЭВМ. 

Эту идею можно развить дальше и говорить о распределе¬ 
нии функций между отдельными частями физической системы. 
Например, интерфейс 7 определяет, какие функции реализуют 
центральные процессоры (ЦП), выполняющие программы, а ка¬ 
кие процессоры ввода-вывода (т. е. каналы). 

Архитектура другого уровня определяет разграничение 
функций между процессорами ввода-вывода и контроллерами 
(устройствами управления) внешних устройств. В свою очередь 
можно разграничить функции, реализуемые контроллерами и 
самими устройствами ввода-вывода (терминалами, модемами, 
накопителями на магнитных дисках и магнитных лентах). Ар¬ 
хитектура таких уровней (интерфейсы 7, 9 и 10) может быть 
названа архитектурой физического ввода-вывода. 

Осталась нерассмотренной архитектура уровней 8 (интер¬ 
фейс между процессором и основной памятью) и 6. Функции 
каждого процессора и контроллера внешнего устройства могут 
быть распределены между микропрограммами и комбинацион¬ 
ными и последовательностными логическими схемами. Следова¬ 
тельно, интерфейс 6 представляет собой интерфейс микропро¬ 
граммы (т. е. обеспечивает согласование потока данных и уп¬ 
равляющих сигналов с форматом микрокоманд) внутри каждого 
процессора. Архитектура уровня 6 может быть названа архитек¬ 
турой микропрограммного управления. Архитектуру уровней 6 и 
8 также часто называют архитектурой процессора или органи¬ 
зацией процессора. 

Последняя разновидность архитектуры, в явном виде не по¬ 
казанная на рис. 1.1, может быть определена как мультипро¬ 
цессорная архитектура (она не представлена на рисунке, по¬ 
скольку отражает скорее вертикальный, чем горизонтальный 
разрез системы). Такая архитектура предусматривает распреде¬ 
ление функций между группой процессоров (например, когда 
вычислительная система должна содержать периферийный про¬ 
цессор для управления базой данных или когда при использова¬ 
нии системы, построенной на микропроцессорах Intel 8086, на 
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одном кристалле реализуется арифметическое устройство с раз¬ 
витой логикой типа 8087) с разграничением функций вычисли¬ 
тельной системы между этими процессорами и определением 
соответствующих интерфейсов. 

Приведенный здесь общий обзор архитектуры различных 
уровней организации вычислительной системы позволяет теперь 
определить термин «архитектура ЭВМ». Архитектура ЭВМ — 
это абстрактное представление или определение физической 
системы (микропрограммы и комплекса аппаратных средств) 
с точки зрения программиста, разрабатывающего программы 
на машинно-ориентированном языке, или разработчика компи¬ 
лятора. Она определяет принципы организации вычислитель¬ 
ной системы и функции процессора и не отражает такие проб¬ 
лемы, как управление и передача данных внутри процессора, 
конструктивные особенности логических схем и специфика тех¬ 
нологии их производства. Иногда (например, в [2]) некоторые 
или все перечисленные здесь проблемы входят в определение 
понятия «архитектура ЭВМ», однако в данной книге подход 
иной, поскольку они представляют отдельные и достаточно точ¬ 
но определенные технические вопросы. 

Таким образом, архитектор ЭВМ должен принять решение 
по трем обширным группам проблем: определить форму пред¬ 
ставления программы для машины и правила ее интерпретации 
этой машиной; установить способы адресации данных в этих 
программах; задать форму представления данных. При реше¬ 
нии каждой из перечисленных групп проблем разработчик архи¬ 
тектуры ЭВМ сталкивается с такими задачами, как определе¬ 
ние минимально адресуемой области памяти, типов и форматов 
данных, кодов операций и форматов машинных команд, спосо¬ 
бов адресации и защиты памяти, механизма управления после¬ 
довательностью выполнения команд, интерфейса машины с 
устройствами ввода-вывода. 

В качестве примера, поясняющего различие между архитек¬ 
турой ЭВМ и архитектурой ее отдельных уровней, можно рас¬ 
смотреть семейство ЭВМ фирмы IBM, получившее название 
Система 360/370, которое разрабатывалось с целью создания 
ряда процессоров, «вписывающихся» в общую архитектуру 
ЭВМ, но имеющих различную внутреннюю структуру для обес¬ 
печения возможности выбора определенных соотношений меж¬ 
ду стоимостью и производительностью вычислительной системы. 
За исключением двух вопросов, техническая документация 
«Принципы работы Системы 370» [3] определяет архитектуру 
ЭВМ для всех процессоров данного семейства. Первое различие 
касается архитектуры процессора — способа, которым процес¬ 
сор «информирует» программное обеспечение о происшедшем 
машинном сбое. Этот вопрос излагается в отдельных руковод- 
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ствах для каждого процессора. Второе различие, выявляющееся 
при описании работы устройств ввода-вывода, заключается в 
отсутствии в упомянутой документации определения командных 
слов канала (терминология Системы 370). Командные слова 
канала определены в отдельных руководствах по эксплуатации 
каждого устройства ввода-вывода. 


РОЛЬ РАЗРАБОТЧИКА АРХИТЕКТУРЫ ЭВМ 

После того как определено понятие «архитектура ЭВМ>, необ¬ 
ходимо выяснить, какая работа возлагается на архитектора — 
разработчика ЭВМ. Согласно изложенному выше, разработка 
архитектуры ЭВМ сводится в основном к установлению границ 
между отдельными уровнями вычислительной системы с много¬ 
уровневой организацией. После предварительного определения 
функций, выполняемых системой в целом, задача архитектора 
ЭВМ состоит в распределении функций системы между отдель¬ 
ными уровнями. Используя набор таких критериев, как стои¬ 
мость, быстродействие, надежность (зачастую эти критерии 
противоречивы), разработчик выясняет, какие функции или час¬ 
ти функций реализуются ниже установленной границы, а какие 
выше. После этого требуется точно указать саму границу (т. е. 
«очертить> пределы действия архитектуры определенного 
уровня). 

Процесс разработки архитектуры ЭВМ может быть струк¬ 
турно представлен таким же образом, как и большинство дру¬ 
гих процессов проектирования системы [4]. В идеальном случае 
разработчик архитектуры ЭВМ должен решать свою задачу в 
следующей последовательности: 1) анализ требований, предъ¬ 
являемых к системе; 2) составление спецификаций; 3) изучение 
известных решений; 4) разработка функциональной схемы; 
5) разработка структурной схемы; 6) отладка проекта; 7) оцен¬ 
ка проекта. 

Этап анализа требований состоит в основном в определении 
общей архитектуры системы с выделением факторов, несущих 
основную функциональную нагрузку. Подобными факторами 
являются количество и специфика требуемых языков програм¬ 
мирования, характеристики периферийных устройств, способ и 
характер взаимодействия с окружающей средой (например, ре¬ 
жим реального времени, телеобработки данных, разделения 
времени, невозможность несанкционированного доступа к систе¬ 
ме, коммерческий или научный характер работ, подлежащих 
выполнению на ЭВМ), требования к операционной системе 
и т. д. 

Анализ требований, предъявляемых к проектируемой систе¬ 
ме, включает также технико-экономические вопросы, связанные 
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с дальнейшей эксплуатацией системы, и вопросы сбыта. Одним 
из важных экономических вопросов является определение коли¬ 
чества систем, которые должны быть изготовлены, поскольку 
этот показатель оказывает существенное влияние на соотноше¬ 
ние между стоимостью аппаратного и программного обеспече¬ 
ния. (Производство программного обеспечения не сопровожда¬ 
ется затратами на изготовление дополнительного оборудова¬ 
ния, если не считать потребность в запоминающих устройствах 
для программ; в то же время производство аппаратных средств 
ЭВМ сопряжено с определенными материальными затратами.) 
Типичной проблемой сбыта является соблюдение требования 
совместимости на определенном уровне (например, на уровне 
языка программирования) разработанной вычислительной си¬ 
стемы и аналогичной системы, находящейся в эксплуатации. 

Составление перечня требований и спецификаций парамет¬ 
ров проектируемой системы включает формулировку используе¬ 
мых критериев и оценку их значимости, определение функций 
системы в соответствии с этими критериями, выявление других 
факторов, таких, как ограничения, накладываемые на парамет¬ 
ры системы (это обусловлено возможностями имеющихся аппа¬ 
ратных средств или разработанной технологией изготовления 
требуемых полупроводниковых элементов и схем). Используе¬ 
мые критерии включают стоимость проектируемой системы, ее 
надежность, трудоемкость реализации, способность к расшире¬ 
нию возможностей, совместимость с системами подобного типа, 
быстродействие, защиту от несанкционированного доступа, гиб¬ 
кость, степень риска успеха проекта в целом, простоту програм¬ 
мирования. Поскольку некоторые из перечисленных критериев 
противоречат друг другу, их следует рассматривать с учетом 
соответствующих приоритетов. 

О необходимости изучения существующих систем и решений 
можно было бы и не упоминать, если бы не столь частое пре¬ 
небрежение этим столь важным этапом процесса разработки 
ЭВМ. 

Разработка функциональной схемы является основным эта¬ 
пом процесса создания архитектуры ЭВМ. Здесь устанавлива¬ 
ются соотношения между различными уровнями организации 
системы в соответствии с необходимыми функциями и предъяв¬ 
ляемыми к системе требованиями, распределяются функции 
между аппаратными средствами и программным обеспечением. 
На этом этапе принимаются решения относительно того, долж¬ 
на ли машина иметь стековую организацию, следует ли преду¬ 
смотреть в ЭВМ операции над числами с плавающей точкой, 
требуется ли обработка прерываний с учетом приоритета. 

На этапе разработки структурной схемы системы определя¬ 
ются до мельчайших подробностей «детали» ее архитектуры. 
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включая определение типов и форматов команд, семантики язы¬ 
ка, способы представления данных, а также способы адресации. 
К сожалению, достаточно простые способы оценки эффективно¬ 
сти принимаемых решений отсутствуют. Нельзя, например, ру¬ 
ководствоваться такими критериями, как: «Сколько будет- 
стоить включение команды X в набор команд?», «Что лучше; 
6 или 8 регистров?», «Во что обойдется введение способа кос¬ 
венной адресации?». Определенную помощь в подобных оцен¬ 
ках может оказать статистика выполнения программ, содержа¬ 
щая, например, такую информацию, как частота использования 
конструкций языка программирования. 

За разработкой структурной схемы системы обычно следует 
этап отладки и оптимизации последней. (Этому вопросу по¬ 
священа гл. 23.) Затем архитектура разработанной ЭВМ оцени¬ 
вается по ряду критериев и требований. Вопросы оценки архи¬ 
тектуры обсуждаются в следующем разделе данной главы я 
во многих последующих главах. 

Отметим, что процесс проектирования архитектуры ЭВМ 
имеет итеративный характер, и обычно приходится многократ¬ 
но повторять отдельные или все этапы проектирования. 

АНАЛИЗ ПРОИЗВОДИТЕЛЬНОСТИ ЭВМ 

При разработке архитектуры ЭВМ наибольшее внимание обыч¬ 
но уделяется проблеме ее производительности. К сожалению, 
эту характеристику часто неправильно понимают, и ее черзвы- 
чайно сложно предсказать и измерить. 

Основная причина неправильной интерпретации упомянутой 
характеристики заключается в том, что ее можно определять 
как на макро-, так и на микроуровне. Однако многие разработ¬ 
чики концентрируют свое внимание только на микроуровне. На 
это указывает использование таких оценок производительности, 
как «время выполнения операций сложения или умножения», 
«число миллионов операций, выполняемых в секунду». Исполь¬ 
зование оценки «число операций в секунду» имеет смысл толь¬ 
ко в том случае, когда сравниваются две реализации одной и 
той же архитектуры. При сравнении же подобных архитектур 
такой подход может легко ввести в заблуждение, а при сравне¬ 
нии существенно отличающихся архитектур он просто бессмыс¬ 
лен. В качестве примера первой ситуации можно использовать 
факт подобия архитектуры Системы 370 и процессора 8085 фир¬ 
мы Intel (о подобии говорить возможно, если провести сравне¬ 
ние этих вычислительных систем с рассматриваемыми в после¬ 
дующих главах). Если оценивать производительность числом 
операций в секунду, то окажется, что микропроцессор 8085 эк¬ 
вивалентен по быстродействию центральному процессору ЭВМ 
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модели 145 Системы 370, хотя в действительности быстродей¬ 
ствие микропроцессора 8085 значительно ниже. 

Термин «производительность» трактуется неверно, поскольку 
его часто отождествляют со скоростью выполнения программы. 
Более правильным является приравнивание его к эффективно¬ 
сти решения задач. Например, какая система имеет более высо¬ 
кую производительность: система, выполняющая программу X 
за 1 мин, но требующая 10 человеко-недель для программиро¬ 
вания и создания отлаженной программы, или система, выпол¬ 
няющая ту же программу X за 2 мин при затратах на програм¬ 
мирование 2 человеко-недель? С позиций микроуровня быстро¬ 
действие первой системы по сравнению со второй в два раза 
выше, с позиций макроуровня — в пять раз ниже. Если же ис¬ 
ходить из широкоизвестных статистических данных о том, что 
85% всех программ выполняется только один раз (т. е. типич¬ 
на ситуация однократного использования программы после раз¬ 
работки и отладки), то такая характеристика архитектуры, как 
простота программирования, является более важной, чем 
скорость выполнения команд. 

Изложенное выше не означает, что скорость выполнения 
программы является несущественным фактором. Важно пони¬ 
мать, что быстродействие зависит как от технологической базы, 
на которой реализуется ЭВМ, так и от архитектуры машины: 
первая влияет на скорость обработки данных, вторая — на 
объем выполняемых работ. Согласно теории вычислений, в пре¬ 
дельном случае возможно построение ЭВМ только с двумя 
командами: увеличения слова на 1 и уменьшения слова на 1 и 
перехода, если значение слова равно 0 .[5]. Нетрудно заметить, 
что общий объем работ (включая выборку, декодирование и 
выполнение команд), выполняемых такой машиной при реали¬ 
зации операции умножения, намного превышает объем работ 
машины, имеющей в наборе команд команду умножения. 

Оценку эффективности архитектуры по скорости выполнения 
программы (например, требуется сравнить архитектуру гипо¬ 
тетической системы А с архитектурой существующей системы Б) 
непосредственно сделать нельзя по следующим причинам: 

1) невозможно выполнить тестовую программу для оценки 
производительности, поскольку архитектура А существует толь¬ 
ко в нашем воображении; 

2) можно построить имитационную модель ЭВМ с архитек¬ 
турой А (используя, например, специальную программу-имита¬ 
тор), но, во-первых, не ясно, какие данные, подлежащие обра¬ 
ботке, следует использовать при моделировании; во-вторых, 
отсутствует информация об аппаратной реализации и стоимости 
производства ЭВМ с архитектурой типа А; в-третьих, всегда 
существует неопределенность относительно реализации модели 
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(например, при моделировании на ЭВМ можно предположить, 
что операция умножения 32-разрядных двоичных чисел со зна¬ 
ком выполняется за 0,5- ІО -9 с, однако аппаратные средства, 
которыми мы располагаем, не могут обеспечить такого быстро¬ 
действия) ; 

3) можно создать машинную реализацию архитектуры А. 
Однако при этом мы столкнемся с проблемой правомочности 
сопоставления машинных реализаций архитектур А и Б по 
таким параметрам, как количество электронных схем, их быст¬ 
родействие и стоимость. Даже если кому-то удастся решить 
эту задачу или найти способ унификации средств реализации 
обеих машин, то в конечном счете все сводится к измерению 
характеристик как архитектур, так и их машинных реализа¬ 
ций. Кроме того, всегда остается неясным вопрос, являются ли 
обе машинные реализации оптимальными по отношению к сво¬ 
им архитектурам, и если нет, то в равной ли степени они неоп¬ 
тимальны; 

4) описанные выше способы оценки архитектуры являются 
весьма дорогостоящими, требуют больших затрат времени, осо¬ 
бенно если необходимо проанализировать большое число раз¬ 
личных архитектурных решений. 

Необходим простой и независимый от машинной реализации 
метод сравнения ЭВМ различной архитектуры по критерию 
эффективности обработки информации. Существуют простые 
приемы получения подобных оценок в первом приближении. 
Речь идет о нескольких характеристиках (параметрах), кото¬ 
рые использовались при проведении исследования с целью на¬ 
хождения простой стандартной архитектуры ЭВМ для всех 
тактических военных систем США [6, 7]. 

Хотя архитектура всех анализируемых вычислительных си¬ 
стем была реализована в конкретных ЭВМ, в процессе иссле¬ 
дования изучалась только относительная эффективность самой 
архитектуры с целью исключения влияния на оценку эффектив¬ 
ности определенной машинной реализации. 

Анализ проводился посредством измерения следующих трех 
параметров: 

S — размер программы; 

М —количество битов, передаваемых между процессором 
и памятью машины (пересылки между регистрами) за время 
выполнения программы; 

R — количество битов, передаваемых между внутренними 
регистрами процессора за время выполнения программы. 

Параметр S — количественная оценка размера программы 
(определяемого длиной команд, размером косвенных адресов, 
объемом рабочих областей для временного размещения дан¬ 
ных). Рациональность использования параметра S мотивирова- 

2* 
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лась ссылкой на него как на «важный показатель пригодности 
ЭВМ данной архитектуры для применения (оцениваемой по 
тестовой программе), который определяет объем памяти, необ¬ 
ходимый для решения задачи» [7]. Например, архитектура 
микропроцессора 8080 мало подходит для копирования в памя¬ 
ти машины блоков данных. Параметр S указывает на это, по¬ 
скольку для выполнения операции пересылки в данном случае 
требуется последовательность из 4 или 5 команд, размещенных 
в памяти, вместо одной команды пересылки. Эта архитектура 



Рис. 1.2. Модель для 
определения «полосы 
пропускания» процессора. 


также неудобна для умножения чисел — отсутствует команда 
умножения. Для программы, в которой требуется умножение, 
параметр S оказывается высоким, поскольку алгоритм пере¬ 
множения чисел реализуется программно. 

Параметр М определяет общее количество битов информа¬ 
ции, пересылаемых между процессором и устройством (уст¬ 
ройствами), на котором реализуется основная память. Этот па¬ 
раметр является определенной оценкой предела эффективности 
выполнения программ почти для всех вычислительных систем, 
обусловленного конечностью «полосы пропускания» (band¬ 
width) интерфейса (произведения числа параллельных линий 
интерфейса на скорость передачи данных) между процессором 
и памятью. Таким образом, объем информации, который дол¬ 
жен быть передан через этот интерфейс (биты команд про¬ 
граммы и данных, пересылаемые в процессор; биты данных, пе¬ 
ресылаемые в память), достаточно точно характеризует эффек¬ 
тивность ЭВМ данной архитектуры. Используя модель, изобра¬ 
женную на рис. 1.2, можно заключить, что если выполнение 
некоторой программы машиной, имеющей архитектуру А, тре¬ 
бует пересылки 6- ІО 6 бит информации, а машиной, имеющей 
архитектуру Б, — 2* 10® бит информации, то в первом прибли¬ 
жении архитектура Б обеспечивает в три раза более высокую 
эффективность, чем архитектура А. 

Как указывалось ранее, параметр М только приблизительно 
характеризует ожидаемую производительность архитектуры не¬ 
зависимо от ее машинной реализации. Важную роль играет 
также близость местоположения используемых данных, т. е. 
локальность ссылок. Например, эффективность работы системы 
существенно зависит от того, являются ли смежными по место¬ 
положению две группы битов информации, выбираемые после- 
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довательно. Поскольку неизвестен способ количественной оцен¬ 
ки локальности ссылок и в связи с тем, что этот показатель за¬ 
висит от машинной реализации архитектуры (разрядности ин¬ 
терфейса доступа к памяти, наличия кэш-памяти), в дальней¬ 
шем он рассматриваться не будет. 

Параметр R используется для оценки той характеристики 
процесса обработки данных, которая не учитывается парамет¬ 
ром М, а именно объема данных, передаваемых внутри про¬ 
цессора. Очевидно, что параметр R в значительной степени 
зависит от машинной реализации процессора, а также таких фак¬ 
торов, как организация процессора и набор функций, выполняе¬ 
мых арифметическо-логическим устройством (АЛУ). При про¬ 
ведении исследований военным ведомством для оценки пара¬ 
метра R была определена некая стандартная внутренняя орга¬ 
низация процессора. В этой книге при сравнении ЭВМ различ¬ 
ной архитектуры используются только параметры S и М. Пара¬ 
метр R не используется по следующим причинам: 

1. Параметр R в значительной степени зависит от машинной 
реализации архитектуры. Поскольку рассматриваемые здесь 
варианты построения архитектуры ЭВМ существенно отлича : 
ются от наиболее распространенного в настоящее время реше¬ 
ния, использование данного параметра для оценки производи¬ 
тельности указанного разнообразия архитектурных решений не 
имеет смысла. 

2. Некоторые весьма произвольные заключения о том, что 
необходимо учитывать и чего не следует учитывать при вычис¬ 
лении параметра R, были сделаны при проведении исследова¬ 
ний военным ведомством [7]. 

3. При проведении тех же исследований было показано, что 
параметр М является более важной характеристикой. 

4. При сравнительном анализе вычислительных систем раз¬ 
личной архитектуры теми же исследователями установлена вы¬ 
сокая степень корреляции между значениями параметров S, 
М и R (см. табл. 1.1). 

Параметры S и М определяются следующим образом: 

S — объем памяти в битах, занимаемый программой и обра¬ 
батываемыми ею данными; 

М — количество битов информации, перемещаемых между 
процессором и памятью в течение времени выполнения про¬ 
граммы. 

При измерении параметра М необходимо принимать во вни¬ 
мание следующие обстоятельства: 

1. Если архитектура ЭВМ предполагает использование 
адресуемых регистров, то они должны рассматриваться как 
часть процессора. При наличии стека необходимо в каждом 
случае определить, находится ли он в памяти или в процессоре. 
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Таблица 1.1. Измерение параметров 2. При определении объема 

S, М и R для 12 тестовых программ передаваемой информаци» 

Архитектура 

S 

м 

всегда существуют ипределеп- 
r ные неясности, связанные с 

_ машинной реализацией архи¬ 

PDP-11 

Система 370 
Interdata 8/32 

1,00 

1,21 

0,83 

0,93 

1,27 

0,85 

тектуры. Например, если ар - 

o';™ хитектура предполагает ис- 

о’вз пользование числовых данных 

_!_ фиксированной длины в до- 


полнительном коде и такой 


команды, как «Переход, если число отрицательное», то теоре¬ 
тически процессору необходимо извлечь из памяти только 1 бит 
команды — знак. В таких случаях оценки должны делаться, ис¬ 
ходя из наиболее рациональной и практически выполнимой ма¬ 
шинной реализации архитектуры. 

3. Существуют аппаратные средства, позволяющие умень¬ 
шить объем информации, пересылаемой между процессором и 
памятью, такие, как буферы и кэш-память. Они не будут рас¬ 
сматриваться, чтобы при сравнении ЭВМ различной архитек¬ 
туры сохранить, насколько это возможно, независимость архи¬ 
тектурного решения от его машинной реализации. 

При использовании параметров S и М желательно распола¬ 
гать некоторой идеальной архитектурой, с которой можно было 
бы сравнивать любую другую архитектуру. Эта проблема «соа- 
рела» для своего решения. Однако попытки определить идеалѣ 
ную архитектуру (например, [8]) сталкиваются с известными 
трудностями, заключающимися в том, что всегда можно пред¬ 
ложить пути совершенствования «идеальной архитектуры».. 
Представляется возможным определить нижнюю границу S и 
М следующим образом: S =0; М=количество битов входных 
данных и результатов обработки. 

Другими словами, можно построить машину, для которой 
не требуется программы (например, единственной функцией 
машины является вычисление преобразования Фурье или выда¬ 
ча платежной ведомости служащих определенной компании). 
Такая машина обрабатывает входные данные только один раз, 
и областей памяти для временного хранения текущей информа¬ 
ции не требуется. Для более универсальной машины, вычис¬ 
ляющей преобразование Фурье или выдающей платежную ве¬ 
домость, нижняя граница параметра S равна 1. 

Как упоминалось выше, разработчика архитектуры ЭВМ 
проблема производительности должна беспокоить значительно 
больше, и он не может ограничиться оценкой средней скоро¬ 
сти выполнения машинных команд. Глобальный подход к опре¬ 
делению производительности требует рассмотрения общей эф¬ 
фективности решения задач на ЭВМ. Даже при рассмотрении; 
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эффективности на микроуровне необходимо уделять определен¬ 
ное внимание трем факторам: языку программирования, компи¬ 
лятору и самой машине. Быстродействие системы обеспечивает 
не скорость выполнения команд, а скорее «мощность» набора 
команд (количество функций, реализуемых машиной). Количе¬ 
ство битов информации, передаваемых между запоминающей 
средой машины и процессором при выполнении данной про¬ 
граммы, оказывают более существенное влияние на потенци¬ 
альную производительность. 

Считается, что разработчик архитектуры ЭВМ первоначаль¬ 
но должен руководствоваться изложенными выше соображе¬ 
ниями. Учитывая, что границы архитектуры ЭВМ проходят на 
стыке аппаратного и программного обеспечения, он должен 
быть хорошо знаком с этими обеими областями. Предложение 
[9] о том, чтобы архитектор новой машины располагал спе¬ 
циально спроектированным, закодированным и отлаженным 
компилятором и операционной системой ранее разработанной 
машины, является недостижимым идеалом, однако такой ход 
рассуждений представляется вполне правомочным. 


УПРАЖНЕНИЯ 


1.1. Целесообразно ли определять архитектуру центрального процессора 
прежде, чем будет определена общая архитектура вычислительной системы? 

1.2. Кто из приводимого ниже списка кандидатов является наиболее 
подходящим для разработки новой архитектуры ЭВМ: прикладной програм¬ 
мист, разработчик компиляторов, разработчик операционной системы или ин¬ 
женер, проектирующий центральный процессор? 

1.3. Проанализируйте архитектуру какой-либо известной вам ЭВМ. Име¬ 
ются ли какие-нибудь свидетельства того, что при разработке этой архитек¬ 
туры большое внимание было уделено достижению компромисса между 
функциями, реализуемыми аппаратными средствами и программным обеспе¬ 
чением, или система проектировалась по принципу снизу — вверх (т. е. от 
аппаратных средств к программному обеспечению)? 

1.4. Приводимые далее две программы, составленные на языке ассембле¬ 
ра, обрабатывают 16-разрядные числа, расположенные последовательно в па- 
памяти, до тех пор, пока не встретится число, равное 0. Слева приведена 
программа для ЭВМ Системы 370, справа —для ЭВМ 8080 фирмы Intel. 


LA R3,l 

L Rl,START 

LOOP LH R2,0(R1) 

LTR R2.R2 

BZ FOUND 

LA R3,1(R3) 

LA R1,2(R1) 

В LOOP 


LXI D,0001 

LHLD START 

MVI A, О 

LOOP MOV B,M 

INX H 

CMP В 

JNZ END 

MOV B,M 

CMP В 

JZ FOUND 

END INX D 

INX H 

JMP LOOP 
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Предполагая, что нулю равно четвертое число (первыми четырьмя числам» 
являются 0001, 0F9D, 0005 и 0000), определите параметры S и М для обеих 
программ. 

1.5. Предположите, что приведенные выше программы являются типич¬ 
ными и позволяют судить обо всех других программах (что, вообще говоря, 
является неверным предположением). Что вы можете сказать: 1) об отно¬ 
сительном объеме памяти, необходимом для архитектуры каждой из систем; 
2) о скорости выполнения программ при эквивалентной машинной реализа¬ 
ции обеих архитектур? 

1.6. Какая часть численного значения параметра М относится к обработ¬ 
ке данных в случае программы Системы 370? 

1.7. Укажите несколько причин, обусловливающих различие численных 
значений параметров S и М для двух рассматриваемых архитектур. 

1.8. Позволяют ли параметры S и М приведенных программ адекватно 
сопоставлять архитектуру вычислительных систем 8080 и 370? 

1.9. Какие из ранее определенных критериев оценки архитектуры (стои¬ 
мость, быстродействие, надежность, защита от несанкционированного досту¬ 
па) вам менее всего понятны? 
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ГЛАВА 2 

КРИТИКА ТРАДИЦИОННОЙ АРХИТЕКТУРЫ 
ФОН НЕЙМАНА 

Главной предпосылкой для написания данной книги явилось 
несоответствие архитектуры большинства современных вычис¬ 
лительных систем тому ее определению, которое дано в гл. 1. 
Вместо того чтобы конструировать систему, исходя из целост¬ 
ности ее принципов и неразрывности взаимодействия аппарат¬ 
ных средств — программного обеспечения, большинство разра¬ 
ботчиков ЭВМ используют традиционный подход и проектиру¬ 
ют систему «снизу вверх», стремясь минимизировать стоимость 
аппаратных средств и возлагая на плечи программистов реше¬ 
ние всех остальных трудных проблем. 

Подтверждением сказанного является отсутствие (за не¬ 
большими исключениями) в архитектуре современных вычисли¬ 
тельных машин существенных изменений и усовершенствований 
по сравнению с архитектурой ЭВМ 50-х годов. Такое утвержде¬ 
ние, звучащее как обвинение, может, конечно, вызвать немед¬ 
ленное возражение с указанием на появление и внедрение прин¬ 
ципов микропрограммирования, поточной (конвейерной) обра¬ 
ботки команд, кэш-памяти, больших и сверхбольших интеграль¬ 
ных схем. Однако все перечисленные усовершенствования не 
являются примерами различных принципов организации архи¬ 
тектуры вычислительной системы. Скорее это достижения в реа¬ 
лизации уже имеющихся архитектурных решений — в организа¬ 
ции процессора или вычислительного процесса. Более того, не¬ 
которые из этих достижений можно рассматривать как шаг 
назад в процессе поиска наилучшей архитектуры вычислитель¬ 
ной системы. Например, внедрение принципа поточной обра¬ 
ботки повлекло за собой появление так называемого «неопре¬ 
деленного» прерывания [1]. Дело в том, что ЭВМ поточной 
обработки оперирует параллельно группой последовательных 
команд и даже может обрабатывать независимые команды, не 
принадлежащие данной последовательности. Как следствие 
этого, при возникновении прерывания ЭВМ иногда не может 
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однозначно определить, какая именно команда вызвала преры¬ 
вание, и не может гарантировать невыполнение команды, непо¬ 
средственно следующей за той, которая вызвала прерывание. 
При работе с ЭВМ поточной обработки программисты получают 
не вполне достоверную информацию о допущенных ошибках и 
предоставлены самим себе в решении вопроса относительно 
того, что же неверно. 

Если сравнить архитектуру большинства наиболее широко 
используемых современных ЭВМ (например, Система 34 и 
Система 370 фирмы IBM, ЭВМ PDP-11, VAX-11, Uni- 
vac 1108, машина 8085 фирмы Intel) с архитектурой первых 
электронных машин с запоминаемой программой EDVAC и 
EDSAC (построенных в 40-х годах), то оказывается, что появ¬ 
ление всех существенных различий датируется 50-ми годами. 
Эти отличительные особенности вычислительных машин, по¬ 
явившихся после машины EDVAC, сводятся к следующим: 

1. Индексные регистры. Позволяют формировать адреса па¬ 
мяти добавлением содержимого указанного регистра к содер¬ 
жимому поля команды. Этот принцип впервые реализован 
в 1949 г. в ЭВМ Манчестерского университета и использован 
в 1953 г. фирмой Electro Data Corporation при производстве 
ЭВМ Datatron. 

2. Регистры общего назначения. Благодаря этой группе ре¬ 
гистров устраняется различие между индексными регистрами 
и аккумуляторами и в распоряжении пользователя оказывается 
не один, а несколько регистров-аккумуляторов. Впервые это ре¬ 
шение нашло свое воплощение, по-видимому, в ЭВМ Pegasus 
фирмы Ferranti (1956 г.). 

3. Представление данных в форме с плавающей точкой. 
Представление данных в виде мантиссы и порядка и выполне¬ 
ние операций над ними было реализовано в 1954 г. в вычисли¬ 
тельных машинах NORC и 704 фирмы IBM. 

4. Косвенная адресация. Средство, позволяющее использо¬ 
вать команды, указывающие адреса, по которым в свою оче¬ 
редь находится информация о местоположении операндов 
команд. Принцип косвенной адресации был реализован в 1958 г. 
в ЭВМ 709 фирмы IBM. 

5. Программные прерывания. При возникновении некоторо¬ 
го внешнего события состояние вычислительной системы, свя¬ 
занное с выполнением прерванной команды, запоминается в 
определенной области. Этот принцип впервые был применен 
в 1954 г. в машине Univac 1103. 

6. Асинхронный ввод-вывод. Параллельно обычному выпол¬ 
нению команд независимые процессоры управляют операциями 
ввода-вывода. Первой ЭВМ с независимым процессором ввода- 
вывода являлась ЭВМ 709 фирмы IBM (1958 г.) 
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7. Виртуальная память. Определение адресного пространства 
программы осуществляется без «привязки» к физическим обла¬ 
стям памяти обычно с целью создания впечатления, что вычис¬ 
лительная система имеет больший объем основной памяти, чем 
тот, которым она фактически располагает. В 1959 г. в вычисли¬ 
тельной системе Atlas Манчестерского университета были реа¬ 
лизованы принципы разделения памяти на страницы и динами¬ 
ческая трансляция адресов аппаратными средствами. 

8. Мультипроцессорная обработка. Два или более независи¬ 
мых процессора обрабатывают потоки команд из общей памя¬ 
ти. Не вполне ясно, кому принадлежит приоритет введения это¬ 
го способа обработки информации, однако в конце 50-х и нача¬ 
ле 60-х годов он был реализован в вычислительных машинах Sage 
фирмы IBM, Sperri-Univac LARC и D825 фирмы Burroughs. 

Хотя существующие в настоящее время вычислительные си¬ 
стемы значительно отличаются от своих предшественниц стои¬ 
мостью, быстродействием, надежностью, внутренней организа¬ 
цией и схемотехническими решениями, архитектура большин¬ 
ства из них не претерпела изменений с 50-х годов. В основном 
она определяется традициями и устаревшими представлениями 
о практической реализации. Эти традиции восходят к первым 
ЭВМ с запоминаемой программой 40-х годов, когда основным 
требованием было решение задач численного анализа (первой 
подобной задачей было решение нелинейных дифференциаль¬ 
ных уравнений) посредством простых программных средств 
общего назначения. Вполне понятно, что возможности разра¬ 
ботчиков ЭВМ были ограничены требованиями минимизации 
стоимости и сложности архитектурных решений. При этом про¬ 
граммное обеспечение и связанные с ним проблемы рассматри¬ 
вались не иначе как курьез. 

Изложенное выше, естественно, должно вызвать следующие 
вопросы: 

1. Являются ли оптимальными на все времена архитектур¬ 
ные решения, предложенные в 40 — 50-х годах? 

2. Достаточные ли изменения претерпели соответствующие 
технологические возможности современного мира (стоимость и 
быстродействие логических схем, диапазон областей примене¬ 
ния вычислительных средств, важность проблем программного 
обеспечения), чтобы считать оправданным внесение существен¬ 
ных изменений в архитектуру ЭВМ? 

СЕМАНТИЧЕСКИЙ РАЗРЫВ 

Поскольку второй важной предпосылкой для написания данной 
книги явилось наличие серьезных недостатков в архитектуре 
современных ЭВМ, прежде чем давать рекомендации по их 
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устранению, целесообразно проанализировать эти недостатки. 
Большинство из них подпадает под определение феномена, из¬ 
вестного как семантический разрыв и предложенного к исполь¬ 
зованию в качестве меры различия принципов, лежащих в ос¬ 
нове языков программирования высокого уровня, и тех прин¬ 
ципов, которые определяют архитектуру ЭВМ [2]. Как прави¬ 
ло, современные вычислительные системы имеют нежелатель¬ 
но большой семантический разрыв, выражающийся в том, что 
объекты манипулирования и соответствующие им операции, 
реализуемые архитектурой вычислительной системы, редко 
имеют близкое «родство» с объектами и операциями, описывае¬ 
мыми в языках программирования. Расширим это определение 
утверждением, что существует большой разрыв в семантике 
между «программным окружением» ЭВМ и представлением 
принципов построения программ на уровне ее архитектуры или, 
развивая эту мысль далее, между архитектурой машины и сре¬ 
дой, в которую ее помещают для использования. Как будет по¬ 
казано ниже, этот большой семантический разрыв обусловлива¬ 
ет возникновение большого количества существенных проблем, 
к которым относятся высокая стоимость разработки про¬ 
граммного обеспечения, его ненадежность и эксплуатационная 
неэффективность, чрезмерный объем программ, сложность ком¬ 
пиляторов и операционной системы, наличие отступлений от 
правил построения языков программирования, т. е. факторы, 
отрицательно влияющие на экономический показатель вычис¬ 
лений. 

Чтобы понять наличие семантического разрыва (согласно 
его определению по отношению к языку программирования и ар¬ 
хитектуре машины), можно выбрать какой-либо язык и архи¬ 
тектуру и заняться изучением взаимосвязей между ними. Для 
этих целей подходит почти любой используемый в настоящее 
время язык программирования и архитектура любой машины. 
В качестве примера проанализируем язык ПЛ/1 и Систему 370. 
Выводы, сделанные в этом случае, будут носить более общий 
характер, поскольку большинство принципов, положенных в ос¬ 
нову ПЛ/1, справедливы и для таких языков, как КОБОЛ, 
ФОРТРАН и Паскаль, а Система 370 отображает большинство 
традиционных архитектурных решений и, кроме того, знакома 
широкой аудитории читателей. 

Указанный анализ предлагается проводить следующим об¬ 
разом: определить принципы, положенные в основу языка про¬ 
граммирования, и попытаться измерить «расстояние» между 
ними и соответствующими принципами, на которых базируется 
анализируемая архитектура вычислительной системы. Ниже пе¬ 
речисляется несколько основных и широко используемых прин¬ 
ципов построения языков программирования, в том числе рас- 
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сматриваемого языка ПЛ/1. Ставится задача определения адек¬ 
ватных принципов, заложенных в архитектуру Системы 370. 

Массивы. Это наиболее часто используемый тип организации 
данных в языке ПЛ/1 и большинстве других языков. Язык ПЛ/1 
предоставляет такие возможности, как использование многомер¬ 
ных массивов, обращение к отдельным элементам массива по¬ 
средством индексов, операции над целыми массивами, обраще¬ 
ние к отдельным подмассивам внутри массива, защиту от вы¬ 
хода за пределы соответствующего массива. В языке Ада эти 
принципы организации массивов расширены дополнительными 
возможностями, в частности возможностью соединения мас¬ 
сивов. 

Анализ архитектуры Системы 370 показывает, что в ней не 
предусмотрены средства, соответствующие описанным принци¬ 
пам организации массивов. Исключением можно считать прин¬ 
цип использования индексных регистров, являющийся прими¬ 
тивным подобием одной из возможностей языка. Следователь¬ 
но, реализация широко используемого принципа организации 
данных в виде массивов возлагается на компилятор, в распоря¬ 
жении которого имеется набор команд Системы 370, весьма 
далекий по своим возможностям от задач, возникающих при 
работе с массивами. (Более подробно эта проблема рассматри¬ 
вается в конце данной главы, в упр. 2.1.) 

Структуры. Это второй тип часто используемой организации 
данных в виде наборов разнородных элементов данных (из¬ 
вестных в некоторых языках программирования под названием, 
записей). И в данном случае в Системе 370 отсутствует сред¬ 
ство, адекватное структурам и операциям над ними. 

Обработка строк. В языке ПЛ/1 применяются так называе¬ 
мые строковые данные (или просто строки) фиксированной и 
переменной длины. Над строками допускается выполнение та¬ 
ких операций, как слияние, выделение заданной части (под¬ 
строки) из исходной строки, поиск строки по заданной подстро¬ 
ке, определение текущей длины строки, проверка присутствия 
элементов одной строки в другой строке. Подобных возможно¬ 
стей в архитектуре Системы 370 не предусмотрено. Конечно,, 
поскольку существуют компиляторы ПЛ/1 для упомянутой си¬ 
стемы, указанные возможности этого языка реализуются по¬ 
средством компиляторов, однако при использовании весьма 
примитивных команд Системы 370. При использовании Систем» 
360 проблемы, «стоящие перед компиляторами», еще сложнее,, 
поскольку команды этой вычислительной системы могут опе¬ 
рировать содержимым областей памяти объемом не более 
256 байт, в то время как строки в ПЛ/1 могут достигать длины 
65 534 байт. Задача манипулирования строками битов (возмож¬ 
ность, предоставляемая языком ПЛ/1) при реализации в Систе- 



30 ГЛАВА 2 


ме 370 осложняется тем, что последняя допускает адресацию 
только к группам из 8 бит (т. е. к байтам). 

Процедуры. Основной структурной единицей языка ПЛ/1 
является процедура или подпрограмма. При вызове процедуры 
требуется сохранение состояния текущей процедуры, динамиче¬ 
ское назначение памяти для локальных переменных вызванной 
процедуры, передача параметров и инициализация выполнения 
вызванной процедуры. В Системе 370, по существу, отсутствуют 
возможности, соответствующие этим принципам организации 
программ на ПЛ/1. Незначительным исключением является 
команда BALR (ПЕРЕХОД С ВОЗВРАТОМ), но ее вклад в 
реализацию операции вызова процедуры столь незначительный 
(это одна из многих команд, подлежащих выполнению при вы¬ 
зове), что ее отсутствие могло бы остаться незамеченным. 
Компилятор мог бы заменить ее двумя другими командами: 
LA (ЗАГРУЗКА АДРЕСА) и BR (ПЕРЕХОД БЕЗУСЛОВ¬ 
НЫЙ). 

Блочная структура. Язык ПЛ/1 имеет блочную структуру, 
предполагающую существование правил определения границ 
областей действия идентификаторов, присваиваемых объектам. 
Эти правила определяют возможность адресации необъявлен¬ 
ных (не получивших имена) переменных ссылок во внутренних 
■блоках. Ничего подобного этому принципу адресации в Системе 
370 нет, и, следовательно, реализация этого принципа должна 
осуществляться генерированием компилятором соответствующе¬ 
го машинного кода. 

ON -блоки}). В языке ПЛ/1 предусмотрена возможность обра¬ 
ботки программных прерываний, вызываемых так называемы¬ 
ми особыми ситуациями: можно указывать для определенных 
исключительных ситуаций обрабатывающие их ON -блоки; дина¬ 
мически назначать и отменять действия ON -блоков; определять 
область их действия в блоках и вызываемых процедурах. В Си¬ 
стеме 370 близким указанным возможностям языка ПЛ/1 мож¬ 
но считать механизм контроля программных прерываний. 
Однако в этой вычислительной системе прерывания обрабаты¬ 
ваются безотносительно к конкретной программе или процессу, 
т. е. в реализации ON -блоков должна участвовать операцион¬ 
ная система. Кроме того, многие особые ситуации в ПЛ/1 (на¬ 
пример, CONVERSION, SUBSCRIPTRANGE, ERROR, NAME, 
CHECK, SIZE) не имеют соответствующих прерываний в Си¬ 
стеме 370, в связи с чем задача генерирования машинного кода 
обнаружения и обработки этих ситуаций возлагается на компи- 
лятор. 

1 ON -блок —это условное обозначение действий, которые программист 
может организовать на языке ПЛ/1 с помощью оператора ON при возникно¬ 
вении особой ситуации, вызывающей программное прерывание — Прим. ред. 
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Представление данных. В языке ПЛ/1 используется пред¬ 
ставление десятичных и двоичных данных в форме с фиксиро¬ 
ванной точкой (целая часть . дробная часть). В Системе 370 по¬ 
добной формы представления нет: десятичные и двоичные дан¬ 
ные имеют вид целых величин, а на компилятор возлагается 
обязанность реализации представления данных в форме с фик¬ 
сированной точкой. При записи на языке ПЛ/1 десятичные чис¬ 
ла могут содержать от 1 до 15 цифр. Что же касается Систе¬ 
мы 370, то здесь допускается представление десятичных чисел, 
содержащих только нечетное количество цифр. Двоичные числа 
на языке ПЛ/1 могут состоять из любого количества цифр в 
пределах от 1 до 31; в Системе 370 количество цифр двоичного 
числа не должно выходить за диапазон значений 15—31. Прв 
записи на языке ПЛ/1 чисел в форме с плавающей точкой ко¬ 
личество значащих цифр числа должно находиться в преде¬ 
лах 1—33; однако представление этих чисел в Системе 370 тре¬ 
бует использования одной из трех форм записи фиксированной 

ДЛИНЫ. 

Подобные рассуждения можно было бы продолжать беско¬ 
нечно, анализируя такие принципы, заложенные в основу язы¬ 
ка ПЛ/1, как управляемая память (стековая организация памя¬ 
ти), вызов общих процедур, функции отслеживания программы 
и автоматическое преобразование данных. Однако приведенных 
здесь примеров, очевидно, достаточно для понимания того, что- 
такое семантический разрыв между принципами языков про¬ 
граммирования высокого уровня и принципами архитектуры 
современных ЭВМ. 

Значение рассмотренных средств программирования зависит 
от того, насколько широко они используются. Даже если и су¬ 
ществует большой подобный разрыв между принципами язы¬ 
ка X и архитектурой соответствующей ЭВМ, при крайней огра¬ 
ниченности использования подобных средств языка и машины 
значимость выявленного семантического разрыва крайне мала. 

Информация, характеризующая программы* весьма ограни¬ 
ченна, но даже те данные, которые имеются, указывают на срав¬ 
нительно частое применение средств программирования, упомя¬ 
нутых в приведенных выше примерах. Так, согласно статисти¬ 
ке, массивы относятся к типичной структуре данных. В соответ¬ 
ствии с работой [3] 9,2% всех обращений к операндам факти¬ 
чески является обращением к элементам массивов. В друго» 
исследовании [4] указывается, что 45% всех арифметических 
операторов имеют дело по крайней мере с одним массивом или 
элементом массива. Даже согласно анализу программ на языке 
КОБОЛ [7], в процессе выполнения программы 30% всех об¬ 
ращений к операндам являются обращениями к элементам мас¬ 
сива. 
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Обращения к процедурам (подпрограммам) используются 
’чаще, чем это принято считать. Авторы работы [3] утвержда¬ 
ют, что 16% выполняемых операторов языка высокого уровня — 
•это обращения к подпрограммам-процедурам, подпрограммам- 
функциям (указателям функций) и операторы возврата. В той 
же работе отмечено, что стандартная процедура (подпрограм¬ 
ма) состоит из восьми или девяти операторов описания, четы¬ 
рех обращений к другим процедурам, одного цикла и одного 
-оператора окончания (например, оператора возврата в вызы¬ 
вавшую процедуру). Исследование работы компилятора языка 
Bliss показывает, что такой компилятор затрачивает 25% свое- 
то рабочего времени на установление связей между подпро¬ 
граммами [5]; для компилятора языка ФОРТРАН подобные 
затраты времени равны 15%. По данным другого исследования 
{7] операторы CALL, RETURN и PROCEDURE составляют 
19% всех операторов программы. 

Статистические данные о программах свидетельствуют о 
том, что в программировании ярко выражена тенденция реше¬ 
ния «нечисленных» задач. В соответствии с работой [4], 18% 
всех используемых переменных представляют собой строки сим¬ 
волов, а 24% всех операторов присваивания предназначены для 
символьной информации. Обширные исследования программ на 
-языке ПЛ/1, проведенные фирмой General Motors [8], показы¬ 
вают, что 27% всех используемых констант — это строки сим¬ 
волов, а не числовые данные. При изучении программ на КО¬ 
БОЛ е [6] обнаружено, что 48% всех данных — строки симво¬ 
лов со средней длиной, равной 24 символам. 
семантический разрыв 

.МЕЖДУ АРХИТЕКТУРОЙ ЭВМ 
-И ОПЕРАЦИОННОЙ СИСТЕМОЙ 

Операционная система — неотъемлемая часть большинства со¬ 
временных вычислительных систем. В общем случае операцион¬ 
ная система выполняет следующие четыре функции: 

1) предоставляет другим программам определенный вид об¬ 
служивания (посредством программ-утилит), например выделе¬ 
ние и назначение памяти, синхронизацию процесса вычислений 
и организацию взаимосвязи между различными процессами 
в вычислительной системе; 

2) обеспечивает защиту (в определенной мере) других про¬ 
грамм от последствий различных особых ситуаций, возникаю¬ 
щих при машинной реализации данной программы, таких, как 
прерывания и машинные сбои; 

3) реализует с той или иной степенью сложности принцип 
«виртуальной машины», что позволяет группе программ исполь¬ 
зовать общие вычислительные ресурсы, например процессор 
(процессоры) и основную память; 
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4)' организует и следит за выполнением принципов управле¬ 
ния при решении таких задач, как обеспечение защиты дан¬ 
ных от несанкционированного доступа и реализация системы 
приоритетов доступа программ к вычислительным ресурсам. 

Для демонстрации семантического разрыва между принципа¬ 
ми, положенными в основу операционных систем, и принципа¬ 
ми, использованными при построении соответствующих вычис¬ 
лительных машин, можно воспользоваться теми же приемами, 
которые применялись выше для иллюстрации разрыва между 
языками программирования и архитектурой соответствующих 
машин. Например, можно сослаться на тот факт, что многие 
разработчики операционных систем признают решающую роль 
модели так называемых рабочих наборов [9] для близкого 
к оптимальному управлению иерархией памяти (например, 
страничной организацией). Но хотя известны средства реали¬ 
зации такой модели [10], они отсутствуют в архитектуре. ЭВМ, 
выпускаемых промышленностью. 

Однако, по-видимому, центральным принципом, «порожден¬ 
ным» операционными системами, является понятие процесса 
как неделимого целого — единицы параллельных операций и 
«обладателя» вычислительных ресурсов. В то же время боль¬ 
шинство современных ЭВМ построено так, как будто этот прин¬ 
цип не получил признания. Задачи синхронизации процессов и 
установления между ними взаимосвязи, решаемые посредством 
так называемых семафоров, критических секций и мониторов, 
а также механизмов приема-передачи, не находят своего вопло¬ 
щения в интерфейсе ЭВМ. 

На операционную систему возлагается также задача по 
разделению информации между «пользователями» и ее защите 
от несанкционированного доступа. Хотя многие архитектурные 
решения ЭВМ потенциально ориентированы на решение подоб¬ 
ной задачи, на практике она обычно реализуется без достаточ¬ 
ной гибкости и относительно произвольно. Например, Систе¬ 
ма 370 обеспечивает защиту памяти поблочно — 2048 байт па¬ 
мяти образуют один блок. Это средство используется для защи¬ 
ты программ друг от друга, но оно бесполезно, если необходимо 
защитить и обеспечить раздельное использование подпрограмм 
и переменных. 

семантический разрыв 

МЕЖДУ АРХИТЕКТУРОЙ ЭВМ И ПРИНЦИПАМИ 
ПОСТРОЕНИЯ ПРОГРАММНЫХ СРЕДСТВ 

Признаки большого семантического разрыва можно также об¬ 
наружить и между принципами, определяющими архитектуру 
ЭВМ, и принципами построения ее программных средств. На¬ 
пример, архитектура современных ЭВМ не содержит никаких 
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специальных аппаратных средств, ориентированных на реали¬ 
зацию таких важных принципов, закладываемых при проекти¬ 
ровании в программное обеспечение больших систем, как мо¬ 
дульность, сокрытие информации, использование абстрактных 
типов данных и мониторов. Хорошо известно, что 50% и более 
денежных средств, затрачиваемых на разработку больших про¬ 
грамм, расходуется на проверку и отладку последних, в то вре¬ 
мя как архитектура современных ЭВМ предоставляет весьма 
мало средств для решения этой проблемы. 

Хотя разработчики ЭВМ принимают во внимание возмож¬ 
ность отказов аппаратных средств, создается впечатление, что 
они считают программы свободными от ошибок. Если и пред¬ 
принимались какие-то меры для исправления неудовлетвори¬ 
тельного положения в указанной области (например, микропро¬ 
цессор 68000 фирмы Motorola содержит команду BOUNDS- 
CHECK, используемую для проверки значения индекса элемен¬ 
та массива относительно верхней и нижней границ последнего), 
то они столь незначительны, что программист, имеющий дело 
с программой, содержащей ошибки, если и получает от аппа¬ 
ратных средств используемой ЭВМ какую-либо помощь, то она 
крайне мала. 

семантический разрыв 

МЕЖДУ АРХИТЕКТУРОЙ ЭВМ 
и организацией памяти 

Этот разрыв обнаружить значительно труднее, чем другие се¬ 
мантические разрывы, поскольку он представляется несуществу¬ 
ющим. И не потому, что проектировщики ЭВМ уже «навели мост 
через эту пропасть», а по той причине, что, в сущности, разра¬ 
ботчики языков и операционных систем «свалились» в нее. 

До сих пор отсутствует единообразный подход к организа¬ 
ции памяти. Архитектура современных ЭВМ такова, что про¬ 
граммист, как правило, имеет несистематизированное, хаотич¬ 
ное представление о памяти машины. Память воспринимается 
им как некая кажущаяся иерархия, в соответствии с которой 
организуются регистры или стеки, запоминающее устройство 
произвольного доступа (основная память), диски, барабаны и 
ленты. Запоминающая среда каждого типа имеет свою систему 
адресации и распределения памяти, свой механизм защиты и 
набор функциональных возможностей. Так, применительно 
к Системе 370 для обращения к данным в основной памяти 
программа должна содержать линейное смещение, добавляемое 
к адресу, хранимому в специальном регистре. Если же данные 
размещены где-либо в другом месте (например, на дорожке 
магнитного диска), то необходимо применить совершенно дру¬ 
гой принцип адресации (требуется использовать номера диско- 
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вода, цилиндра, дорожки, записи, а также линейное смещение 
в пределах записи). Для выполнения над некоторыми данными 
такой операции, как сложение, программисту необходимо при¬ 
нимать во внимание ту запоминающую среду, в которой нахо¬ 
дятся данные, ибо операция сложения определена только для 
подмножества всего разнообразия запоминающих сред. Если 
данные размещены в основной памяти, то сложение можно вы¬ 
полнить непосредственно; если же они находятся на диске, то 
требуется не только прибегнуть к другому типу адресации, но и 
создать специальную программу (цепочки управляющих слов 
канала), чтобы при использовании Системы 370 скопировать 
данные в основную память, что необходимо для выполнения 
операции сложения. 

Вместо того чтобы сформулировать новые принципы реше¬ 
ния подобной проблемы, создатели языков программирования 
разработали модели организации памяти, повторяющие те, ко¬ 
торые заложены в архитектуру соответствующих ЭВМ. В ре¬ 
зультате семантического разрыва не существует, но его отсут¬ 
ствие нельзя признать положительным решением проблемы. 
Программисту, работающему на языках высокого уровня, пре¬ 
доставляется не единая систематизированная структура органи¬ 
зации памяти, а некоторое количество невзаимосвязанных прин¬ 
ципов организации, определяемых возможностями технологии 
производства и практической применимостью. 

Отметим, что принципы виртуальной памяти в том виде, в 
каком они воплощены в современных вычислительных системах, 
не решают указанной здесь проблемы. Чаще всего виртуальная 
память создает у программиста лишь иллюзию наличия боль¬ 
шего объема основной памяти, чем она есть в действительно¬ 
сти, а это ничего не добавляет к решению проблемы отсутствия 
единого подхода к организации памяти. 

ПОСЛЕДСТВИЯ 
СЕМАНТИЧЕСКОГО РАЗРЫВА 

Простое указание на наличие семантического разрыва несколь¬ 
ких типов не обязательно влечет за собой необходимость вне¬ 
сения улучшений в архитектуру ЭВМ. Потребность в них ста¬ 
новится очевидной в результате анализа последствий, к кото¬ 
рым приводит указанный семантический разрыв. Этому вопро¬ 
су и посвящены следующие ниже разделы. 

НЕНАДЕЖНОСТЬ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 

Семантический разрыв существенно влияет на ненадежность 
программного обеспечения в том смысле, что значительная до¬ 
ля ошибок программирования, которые теоретически могли бы 
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быть предотвращены или обнаружены вычислительной систе¬ 
мой, не выявляются системами, находящимися в эксплуатации 
в настоящее время. Ограничимся здесь лишь несколькими при¬ 
мерами. Более детальное обсуждение этого предмета будет сде¬ 
лано в последующих главах, особенно в части V. 

Типичной ошибкой программирования, возникающей в са¬ 
мых разнообразных ситуациях, является обращение к перемен¬ 
ной, значение которой не определено или не установлено. Боль¬ 
шинство современных вычислительных систем не обнаруживает 
подобной ошибки, а поскольку выполнение программы продол¬ 
жается и используется непредсказуемое значение переменной 
(программа начинает носить недетерминированный характер), 
выявить и устранить ошибку чрезвычайно трудно. Причина по¬ 
следнего обстоятельства заключается в том, что, хотя на эта¬ 
пе компилирования в какие-то моменты ошибка и может быть 
обнаружена путем анализа хода алгоритма, в общем случае 
выявление ошибки возможно не ранее наступления этапа вы¬ 
полнения. Поскольку традиционные машины не располагают 
средствами установления факта присутствия (или отсутствия) 
значения переменной, эта проблема оказывается переложенной 
с разработчика архитектуры ЭВМ на разработчика компиля¬ 
тора. А так как последний не находит простого и эффективного 
решения этой проблемы, он в свою очередь перекладывает ее 
решение на программиста — составителя прикладных программ, 
что делает описываемую ошибку наиболее часто встречающейся 
в современном программировании [11]. 

При создании некоторых компиляторов предпринимались 
попытки решения указанной проблемы, однако используемые 
средства оказались сложными, неэффективными и не предо¬ 
ставляли возможности подтверждения отсутствия ошибок. На¬ 
пример, компилятор языка ПЛ/1 с диагностикой ошибок, раз¬ 
работанный фирмой IBM, присваивает в качестве начального 
значения всем строкам символов значение шестнадцатеричных 
символов FE (знак ш спецификации формата), всем двоичным 
числам с фиксированной точкой — значение наименьшего отри¬ 
цательного числа, а затем проверяет эти значения при каждом 
обращении к указанным переменным. Однако введение такой 
меры не только увеличивает расход машинного времени и па¬ 
мяти, но может привести к обнаружению «ошибок» в правиль¬ 
ных программах; при этом описываемый метод не охватывает 
все типы переменных. Позже будет показано, что рассматривае¬ 
мая ошибка программирования может быть выявлена букваль¬ 
но без всяких затрат при соответствующем выборе архитекту¬ 
ры ЭВМ. 

Другой типичной ошибкой является обращение к элементу 
массива, один из индексов которого выходит за соответствую^ 
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щие границы. Поскольку для традиционной машины такого 
понятия, как массив, не существует, и в этом случае также от¬ 
ветственность за решение данной проблемы возлагается на раз¬ 
работчика компилятора. Так как простые ответы на вопрос, по¬ 
ставленный последнему, не известны, эта проблема либо игно¬ 
рируется вовсе, либо ее решение путем введения соответст¬ 
вующего контроля возлагается на программиста, составляющего 
прикладные программы. Но для установления такого контроля 
требуются существенный дополнительный объем памяти и ма¬ 
шинное время. Поэтому в руководстве по программированию 
разработчик компилятора предупреждает: «С целью экономии 
памяти и машинного времени рекомендуется использовать по¬ 
добный контроль только на этапе тестового прогона программ 
с последующим удалением средств контроля из конечного про¬ 
дукта— рабочей программы» [12]. Такое решение может вы¬ 
звать возражения, поскольку оно «подобно предложению мо¬ 
ряку пользоваться спасательным жилетом при тренировках на 
суше, а при выходе в море не надевать его» [13]. Другими 
словами, кажется странным предложение о проверке наличия 
ошибок на этапе тестовых прогонов программы (когда оши¬ 
бочные результаты вовсе не опасны) и удалении средств про¬ 
верки из рабочей программы (когда ошибочный результат мо¬ 
жет привести к катастрофическим последствиям). 

Язык Ада тоже предоставляет программисту возможность 
изымать некоторые или все средства контроля из программы 
в процессе ее выполнения. Однако к достоинствам этого языка 
следует отнести, во-первых, функционирование контроля, если 
последний специально не отменен, и, во-вторых, отсутствие 
требования к компилятору просматривать программу с целью 
поиска запросов на подавление средств контроля. 

Примером затрат машинного времени и памяти на выполне¬ 
ние контроля программными средствами является работа ком¬ 
пилятора языка ПЛ/1 фирмы IBM, генерирующего 17 машин¬ 
ных команд (занимающих 62 байт памяти) для оператора 
C(I,J)=A(I,J)+(BJ,1); 

где А, В и С — массивы двоичных элементов одинакового раз¬ 
мера в форме с фиксированной точкой. Если необязательное 
средство контроля SUBSCRIPTRANGE подключено, то компи¬ 
лятор генерирует 75 машинных команд (274 байт); причем из 
них выполнению подлежит лишь 57 команд, если значения ин¬ 
дексов переменных не выходят за допустимые пределы. Следо¬ 
вательно, это средство контроля увеличивает объем памяти, 
занимаемый объектным кодом указанного оператора, до 340%, 
а время выполнения оператора возрастает в три раза. В даль¬ 
нейшем будет показано, что подобный контроль может быть в№- 



полнен машиной без всякого увеличения объема памяти и за¬ 
трат машинного времени. (Машина, обнаруживающая такую 
■ошибку, вероятно, должна быть более быстродействующей, как 
показано в гл. 4, поскольку в ее архитектуре отражен принцип 
организации данных в форме массивов.) 

Дж. Вейзенбаум в книге, посвященной этике вычислений 
[14], при описании работы ЭВМ в терминах, понятных неспе¬ 
циалистам, указывает на существование семантического раз¬ 
рыва и его взаимосвязь с надежностью: 

«Работа вычислительных машин поразительно легко нару¬ 
шается чисто техническими, т. е. лингвистическими, программ¬ 
ными ошибками, однако эти нарушения таковы, что их истин¬ 
ная причина скрыта, замаскирована. Причиной затруднений, с 
которыми сталкиваются при программировании, является в 
большинстве случаев то обстоятельство, что машине в дейст¬ 
вительности ничего не известно о тех сторонах реального мира, 
с которыми программа должна иметь дело... (так, недопустимо 
высказывание типа 2,999 человек). Довольно трудно объяснить 
что-либо (например, лингвистические концепции) в терминах 
примитивного словарного запаса (т. е. машинными команда¬ 
ми), не имеющего ничего общего с тем, что подлежит объясне¬ 
нию... Для написания хорошего сонета или хорошей программы 
необходимо понимать, что нужно выразить. И конечно, благо¬ 
творна ситуация, когда критик (машина) располагает знания¬ 
ми, адекватными тем, которые находятся в распоряжении объек¬ 
та критики (языка программирования)». 

ПРОБЛЕМЫ ЭФФЕКТИВНОСТИ ЭВМ 

Большой семантический разрыв порождает также и значитель¬ 
ные проблемы, связанные с уменьшением эффективности работы 
вычислительной машины вследствие того, что, располагая толь¬ 
ко довольно примитивным набором машинных команд для реа¬ 
лизации возможностей языка программирования, компилятор 
вынужден генерировать, а машина интерпретировать большое 
число команд. Это снижает скорость выполнения задания на 
ЭВМ, поскольку увеличивается объем информации, которой 
обмениваются память и процессор. Как показано в гл. 1, ве¬ 
личина этого объема является хорошим критерием первого по¬ 
рядка для сравнения производительности различных машин. 

Рассмотрим отмеченное явление на простом примере. Допус¬ 
тим, что необходимо сложить две матрицы целых чисел размер¬ 
ностью ЮОхЮО. Средствами языка ПЛ/1 решение можно 
сформулировать в следующем виде: А=А+В; использование 
для этих целей вложенного цикла DO значительно более неэф¬ 
фективно. Компилятор языка ПЛ/1 Системы 370 генерирует для 
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этого оператора эффективный объектный код шесть команд, 
за которыми следует цикл из четырех команд, выполняемых 
10 000 раз. Общее количество 32-битовых слов, подлежащих пе¬ 
ремещению между памятью и процессором, равно 70 007. Из 
этого количества 40 004 — это команды, первые шесть из кото¬ 
рых укладываются в четыре слова, и четыре слова занимает 
тело цикла , а 30 003 — это данные. Значения двух данных из¬ 
влекаются из памяти, а результат операции над ними записы¬ 
вается в память при обработке каждой пары элементов масси¬ 
вов (к этому добавляется еще несколько выбираемых из памяти 
данных). Однако если бы компилирование выполняла машина, 
в архитектуре которой отражен принцип организации данных в 
форме массивов (например, машина, описываемая в части V), 
то могло бы оказаться достаточно одной машинной команды: 
(прибавление В к А) при объеме слов, перемещаемых между 
памятью и процессором, порядка 30 000 (к этой величине сле¬ 
дует добавить одно слово для команды и, возможно, еще не¬ 
сколько для информации, описывающей массивы). Кроме того, 
если первая из упомянутых машин должна декодировать и ин¬ 
терпретировать 40004 команды, то вторая только декодирует 
одну команду. Конечно, имеются и другие показатели эффек¬ 
тивности работы машины, кроме количества пересылок между 
памятью и процессором и объема работ по декодированию 
команд (например, вычисление адресов и выполнение арифме¬ 
тического сложения), но эти показатели примерно одинаковы 
для обеих машин. 

Хотя рассмотренный пример справедлив только для опера¬ 
ций с массивами, можно найти аналогичные примеры генериро¬ 
вания чрезвычайно большого количества команд при реализа¬ 
ции на традиционных ЭВМ почти каждого принципа, положен¬ 
ного в основу языка программирования. 

Семантический разрыв между языком программирования и 
архитектурой машины при описании и реализации процедур 
ввода-вывода также вносит определенный вклад в общую не¬ 
эффективность вычислительных систем. Вместо того чтобы 
снабдить программиста памятью, единой по своим принципам 
организации на всех уровнях иерархии, современные средства 
вычислительной техники понуждают программиста управлять 
памятью с учетом уровня иерархии. Иначе говоря, в настоящее 
время иерархией памяти системы управляют прикладные про¬ 
граммы, вследствие чего достигается не глобальная, а лишь ло¬ 
кальная оптимизация использования вычислительных ресурсов. 
Примером может служить двойное буферирование — техниче¬ 
ский прием, обеспечивающий эффективное решение задачи оп¬ 
тимизации для одиночной программы, но вовсе не обязательно 
оптимально использующий вычислительные ресурсы системы 
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при одновременном выполнении нескольких программ. Зачем 
растрачивать циклы выполнения команд, которые управляют 
буферами или перемещают записи, если вместо этого можно 
было бы использовать машинное время на выполнение другого 
процесса? 

ЧРЕЗМЕРНО БОЛЬШОЙ РАЗМЕР ПРОГРАММЫ 

Рассматриваемый семантический разрыв отрицательно сказыва¬ 
ется не только на эффективности работы машины, но и на раз¬ 
мере программы: компиляторы должны генерировать большое 
количество машинных команд, чтобы компенсировать последст¬ 
вия этого разрыва. Например, ранее упоминалось, что для 
представления оператора 

C(I,J)=A(I,J)+B(I,J); 

необходимо 62 байт памяти, если не требуется контроля значе¬ 
ний индексов, и 274 байт, если подобный контроль желателен. 
При использовании машины, описываемой в части V, этот опе¬ 
ратор может быть представлен двумя машинными командами, 
занимающими вместе 13 байт памяти (при автоматическом вы¬ 
полнении указанного контроля). 

Несмотря на постоянные заявления о том, что «дефицит па¬ 
мяти вскоре исчезнет», потребность в ее увеличении все еще 
остается одной из проблем, с которой сталкиваются при исполь¬ 
зовании ЭВМ. Это объясняется несколькими причинами. Во- 
первых, стоимость памяти относительно высока. Так, стоимость 
основной памяти микропроцессорной системы часто превосхо¬ 
дит стоимость процессора на порядок и более. Во-вторых, по¬ 
требность в памяти увеличивается примерно с той же скоро¬ 
стью, с которой падает ее стоимость. В-третьих, чрезвычайно 
большой размер программ, обусловленный неэффективностью 
организации вычислительной системы в целом, вызывает не¬ 
обходимость в рабочих наборах 1 ). 

сложность компилятора 

Материал, рассмотренный в двух предыдущих подразделах, де¬ 
лает очевидным наличие семантического разрыва между прин¬ 
ципами, лежащими в основе архитектуры машины, и принципа¬ 
ми, определяющими построение компилятора языка программи¬ 
рования. Механизм генерирования машинных кодов в компиля¬ 
торе должен быть чрезвычайно сложным, чтобы эффективно 
ликвидировать семантический разрыв. 

Может возникнуть вопрос о том, может ли сокращение раз- 

1 По-видимому, речь идет о наборах страниц виртуальной памяти, одно¬ 
временно находящихся в реальной памяти. — Прим. ред. 
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рыва устранить указанную сложность структуры компилятора, 
поскольку эта сложность где-то локализуется. Если разрыв со¬ 
кращается за счет усложнения архитектуры машины, то упомяг 
нутая сложность «переместится» из компилятора в машину. 
Подобный обмен упрощает структуру компилятора по двум при¬ 
чинам. Во-первых, если допустить, что вычислительная система 
располагает более чем одним компилятором (для Системы 
370 написаны сотни компиляторов), то семантический разрыв 
должен быть преодолен либо в каждом компиляторе, либо од¬ 
нократно при реализации машины. Например, если всем исполь¬ 
зуемым системой языкам программирования присущи такие 
средства, как описания массивов и вызовы процедур, то пред¬ 
ставляется более разумным (даже без учета других возмож¬ 
ных сопутствующих преимуществ) ликвидировать этот разрыв 
один раз путем соответствующей модификации архитектуры 
машины, чем делать это для каждого компилятора. Во-вторых, 
желаемого результата можно добиться, если решение этой проб¬ 
лемы частично возложить на машину, а частично — на компи¬ 
лятор с обеспечением хорошего интерфейса (согласования) 
между этими частями. В этом случае решение, как правило, 
достигается более простыми средствами. 


ИСКАЖЕНИЯ ЯЗЫКА ПРОГРАММИРОВАНИЯ 
И ЕГО НЕКОРРЕКТНОЕ ИСПОЛЬЗОВАНИЕ 

Если семантический разрыв столь велик, что компилятор не мо¬ 
жет эффективно преодолеть его полностью, то в определении 
языка программирования появляются искажения (нарушения 
правил его построения), которые в машине, реализующей язык, 
учесть нельзя. Вследствие этого возможно некорректное исполь^ 
зование языка. 

В качестве примера предположим, что при работе с Систе¬ 
мой 370 с использованием языка ПЛ/1 программист объявляет 
переменную А десятичным числом с фиксированной точкой, со¬ 
стоящим из двух цифр (разрядов). При использовании опера¬ 
тора присваивания А=100 естественно было бы ожидать сооб¬ 
щения об ошибке. Однако этого не происходит, и при выводе 
значения А на печать появится число 100. Объясняется это тем, 
что Система 370 может представлять десятичные числа, имею¬ 
щие только нечетное количество цифр. Предвидя, что полное 
устранение семантического разрыва привело бы к генерирова¬ 
нию неэффективных объектных кодов, разработчики компилято¬ 
ра предпочли преобразование двухразрядных десятичных пере¬ 
менных языка ПЛ/1 в трехразрядные операнды машины. Дру¬ 
гая возможная альтернатива — изменение соответствующего 
правила языка ПЛ/1 — могла бы в равной степени приводить 
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в замешательство программистов и повлечь за собой излиш- 
«юю ориентацию языка на архитектуру Системы 370. 

Для иллюстрации рассматриваемой проблемы можно обра¬ 
тить внимание на тот факт, что язык ПЛ/1 допускает десятич¬ 
ное и двоичное представления чисел. Трудно понять, зачем 
программисту, работающему на этом языке, пользоваться 
двоичным представлением, поскольку если в его распоряжении 
находится переменная М, определенная как двоичное число 
с фиксированной точкой, то для присвоения ей значения 25 не¬ 
обходимо воспользоваться оператором присваивания 
М= 11001В; 

Большинство лиц, программирующих на языке ПЛ/1, по не¬ 
внимательности записывают М=25, но 25 — число десятичное, 
поэтому средства языка должны запрашивать автоматическое 
преобразование данных, использование которого при недоста¬ 
точном опыте может повлечь за собой много странных ошибок 
[15]. Однако при работе с Системой 370 на языке ПЛ/1 многие 
программисты пользуются двоичными числами потому, что де¬ 
сятичные числа занимают больший объем памяти, а выполнение 
десятичных операций требует значительно большего времени. 
•Следовательно, архитектура используемой ЭВМ побуждает 
программиста к некорректному использованию языка програм¬ 
мирования. 

В качестве еще одного примера применительно к языку 
ПЛ/1 рассмотрим использование переменных в формате строки 
битов. Неискушенный программист, пытающийся передать зна¬ 
чение такой переменной в другую процедуру через список па¬ 
раметров, часто сталкивается с неожиданным результатом. По¬ 
скольку в Системе 370 допустима адресация только на границу 
байта, а строка битов вовсе не обязательно начинается с такой 
границы, между двумя процедурами возможно возникновение 
проблемы выравнивания данных на границу памяти. Читатель, 
имеющий опыт программирования на языке ПЛ/1, возможно, 
знает, что атрибут ALIGNED был добавлен к средствам этого 
языка для решения проблем подобного типа. Это — еще одно 
указание на влияние архитектуры машины на язык программи¬ 
рования. 

Искажения можно найти и в других языках. Например, в 
языке ФОРТРАН арифметический оператор IF передает управ¬ 
ление одному из трех операторов в зависимости от значения 
вычисляемого выражения — является ли оно отрицательным, 
равным нулю или положительным. Это связано не с эстетиче¬ 
скими концепциями структуры языка программирования, а 
с наличием в ЭВМ 704 фирмы IBM команды сравнения, по ре¬ 
зультату выполнения которой управление передается одной из 
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трех последующих команд. Другой особенностью языка 
ФОРТРАН является тот факт, что для цикла, формируемого по¬ 
средством оператора DO, всегда необходимо выполнение по 
крайней мере одной итерации. Это требование также обуслов¬ 
лено машиной, реализующей Фортран-программу, а именно ис¬ 
пользованием в ЭВМ 704 команды ТІХ. 

Язык Ада — свидетельство компромиссов, которые необхо¬ 
димы для организации надежного программирования при ис¬ 
пользовании современных машин. Последние не обеспечивают 
корректное использование типов переменных (допуская, напри¬ 
мер, применение в командах несовместимых операндов, не реа¬ 
гируя на подмену формальных параметров фактическими и на¬ 
оборот) и не выявляют обращения за допустимое адресное 
пространство (не обнаруживают, что используемый адрес более 
недействителен). Для устранения этих ошибок и ошибок дру¬ 
гих типов разработчики языка Ада предпочли ограничить гиб¬ 
кость языка так, чтобы подобные ситуации можно была 
предотвратить или обнаружить на этапе компилирования. В ре¬ 
зультате подобных компромиссов язык становится менее гиб¬ 
ким (язык ПЛ/1 содержит некоторые средства программирова¬ 
ния, отсутствующие в языке Ада), но более надежным (мень¬ 
шее количество ошибок остается необнаруженным) при исполь¬ 
зовании машин современной архитектуры. 

НИЗКАЯ ПРОДУКТИВНОСТЬ ПРОГРАММИРОВАНИЯ 

Стоимость разработки программного обеспечения стала глав¬ 
ным препятствием на пути дальнейшего роста объема вычисле¬ 
ний. В то время как достигнуто значительное снижение стоимо¬ 
сти аппаратных средств вычислительной техники, затраты на 
разработку программного обеспечения остаются относительна 
постоянными. Частично это объясняется наличием семантиче¬ 
ского разрыва. 

Примером существенного препятствия повышению продук¬ 
тивности программирования является семантический разрыв, 
обусловленный отсутствием общего, единого подхода к органи¬ 
зации памяти ЭВМ. Большинство трудностей, которые возника¬ 
ют при использовании прикладных программ, связаны с управ¬ 
лением памятью, т. е. этим программам должно быть известно 
о том, что основной файл записан на диске, и их команды 
должны явным образом осуществлять пересылку записей между 
диском и основной памятью. Можно с уверенностью сказать, 
что программист, разрабатывающий прикладную программу, 
затрачивает больше времени на управление памятью и переме¬ 
щение данных, чем на преобразование последних. Согласно упо¬ 
мянутому ранее анализу программ на языке ПЛ/1 [8] , каждый 
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из 20 операторов — оператор ввода или вывода. Для программ 
на языке КОБОЛ [6] 19% всех операторов программы являют¬ 
ся операторами ввода или вывода. Если бы можно было от¬ 
казаться от процедур ввода-вывода, стоимость разработки про¬ 
грамм сократилась бы вдвое и более. 

Анализ затрат на разработку программного обеспечения 
содержится в последующих главах. Как отмечает Дж. Деннис 
[16], «нельзя ожидать значительных улучшений методологии 
разработки очень больших программ при отсутствии существен¬ 
ных изменений в структуре аппаратных средств и организации 
вычислительных систем». 

ОГРАНИЧЕНИЯ НА ВЫБОР ВАРИАНТА 
ПОСТРОЕНИЯ МАШИНЫ 

Еще одним следствием наличия семантического разрыва явля¬ 
ется появление определенных ограничений на организацию про¬ 
цессора. Применение принципа параллелизма операций пред¬ 
ставляется важнейшим способом преодоления пределов быст¬ 
родействия аппаратных средств, однако архитектура низкого 
уровня ограничивает возможности проектировщика в его стрем¬ 
лении использовать данный принцип только двумя вариантами 
обработки — мультипроцессорной и поточной. Располагая архи¬ 
тектурой низкого уровня с такими примитивными командами, 
как LOAD REGISTER (ЗАГРУЗКА РЕГИСТРА) и ADD 
INTEGER (СЛОЖЕНИЕ ЦЕЛОЧИСЛЕННОЕ), конструктор 
не способен найти применение принципа параллелизма, кроме 
как частично перекрывая во времени выполнение последова¬ 
тельных команд. Другое решение — мультипроцессорная обра¬ 
ботка — приводит лишь к частичному успеху из-за проблем, 
возникающих при ее реализации (в частности, перекрытия об¬ 
ластей памяти и сложности синхронизации), и проблем про¬ 
граммирования (трудность декомпозиции задачи на параллель¬ 
но решаемые подзадачи и сложность реализации в компилято¬ 
рах средств обнаружения в программах последовательностей 
команд, подлежащих параллельному выполнению) [17]. 

В последующих главах показано, что сокращение семанти¬ 
ческого разрыва требует от машины большего «понимания» 
того, что она делает: ее операции должны единовременно охва¬ 
тывать значительно больший фрагмент общей работы. Послед¬ 
нее предоставляет инженеру широкие возможности для исполь¬ 
зования принципа параллелизма. 

Подводя итоги, можно сказать, что свойственный современ¬ 
ным вычислительным системам семантический разрыв порож¬ 
дает много существенных недостатков, которые в свою очередь 
отрицательно сказываются на экономических факторах разра¬ 
ботки и использовании вычислительных систем. 
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АРХИТЕКТУРА 4>0Н НЕЙМАНА 

Основная причина существования большого семантического раз¬ 
рыва в современных вычислительных системах заключается в 
том, что их архитектура, по существу, не отличается от архи¬ 
тектуры модели ЭВМ, предложенной Дж. фон Нейманом в 
40-х годах [18]. Это не означает, что архитектуре фон Неймана 
не были присущи признаки гениального творения. Но со време¬ 
ни ее создания мир претерпел громадные изменения. Поскольку 
в то время практическая пригодность даже конструируемых 
электронных вычислительных машин ставилась под сомнение и 
главное внимание обращалось на стоимость аппаратных средств 
и надежность машины, основная задача заключалась в проекти¬ 
ровании процессора настолько примитивным, насколько это воз¬ 
можно. А такие столь существенные для сегодняшнего дня фак¬ 
торы, как наличие языков программирования высокого уровня, 
сложность и «чувствительность» (к побочным явлениям) под¬ 
лежащих решению задач, не только не принимались в то время 
во внимание, но и оставались незамеченными. И если учесть, 
что архитектура фон Неймана разрабатывалась для решения 
определенной проблемы — обеспечения пользователя простым 
устройством с запоминаемой программой, предназначенным для 
выполнения вычислений с целью решения дифференциальных 
уравнений, — остается только удивляться, что эта архитектура 
сохранилась в наши дни. 

По существу, все современные ЭВМ можно классифициро¬ 
вать как машины фон Неймана. Принято считать, что машине 
с архитектурой фон Неймана присущи следующие характери¬ 
стики: 

1. Единственная последовательно адресуемая память. Про¬ 
грамма и данные хранятся в одной памяти, адреса областей 
которой составляют последовательность типа 0, 1,2, ... 

2. Память является линейной. Она одномерная, т. е. имеет 
вид вектора слов. 

3. Отсутствует явное различие между командами и данными. 
Их идентифицируют неявным способом при выполнении опера¬ 
ций. Так, объект, адресуемый командой перехода, определяется 
как команда; операнды, с которыми имеет дело команда сло¬ 
жения, определяются как данные. Эти принимаемые по умол¬ 
чанию соглашения позволяют, например, обращаться с коман¬ 
дой как с данными (в частности, модифицировать ее), склады¬ 
вать команду со словом данных или осуществлять переход 
к слову данных и выполнять его так, как будто бы биты этого 
слова представляют команду. 

4. Назначение данных не является их неотъемлемой состав- 
«ой частью. Нет, например, никаких средств, позволяющих явно 
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отличить набор битов, представляющих число с плавающей точ¬ 
кой, от набора битов, являющихся строкой символов. Назначе¬ 
ние данных определяется логикой программы. Если машина из¬ 
влекает из памяти команду сложения чисел с плавающей точ¬ 
кой, то предполагается, что операнды — числа с плавающей 
точкой, и над операндами выполняется сложение согласно пра¬ 
вилам арифметики чисел с плавающей точкой. Следовательно,, 
можно выполнить подобное сложение над двумя операндами* 
являющимися в действительности, например, строкой символов- 
и адресом. 

Хотя архитектура фон Неймана была логичным решением 
проблемы создания первой машины с запоминаемой програм¬ 
мой, она не удовлетворяет требованиям, которые выдвигает за¬ 
дача выполнения программ, написанных на языках высокого* 
уровня. В отличие от перечисленных выше четырех характери¬ 
стик языки высокого уровня имеют следующие характеристики; 

1. Память, согласно ее представлению в языке высокого! 
уровня, состоит из набора дискретных именуемых переменных- 
За исключением некоторых вызывающих разногласие конструк¬ 
ций языка (таких, как общая область в языке ФОРТРАН)* 
здесь отсутствует принцип размещения одной переменной ря¬ 
дом с другой. Нет никаких оснований полагать, что переменные 
одной подпрограммы расположены в том же запоминающем 
устройстве, что и переменные другой подпрограммы. Таким 
образом, принцип единственной последовательной памяти мало* 
напоминает принцип организации памяти, формулируемый н 
соответствии с требованиями языков программирования. 

2. Языки программирования оперируют многомерными, а не 
просто линейными данными (в языках имеются массивы, струк¬ 
туры, списки). 

3. Языкам программирования присуще резкое разграничение 
между данными и командами. В большинстве языков отсутст¬ 
вует возможность обработки данных или обращения к коман¬ 
дам, как будто бы они данные. 

4. В языках высокого уровня назначение данных является 
внутренней частью самих данных. Вместо записи вида 

DECLARE A WORD; 

' DECLARE В WORD; 

А=А «сложение с плавающей точкой» В; 
в программах записывают 

DECLARE A DECIMAL FLOAT (6); 

DECLARE В DECIMAL FLOAT (6); 

A=A+B; 

Иначе говоря, в языках высокого уровня назначение дан¬ 
ных связано с самими данными; данные определяют и опера- 
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ции, выполняемые над ними (например, действие символа «Н-» 
определяется свойствами операндов этой операции). 

Итак, принципы, на которых основывается архитектура фон 
Неймана, не согласуются с принципами языков программиро¬ 
вания и даже им противоречат. Машина фон Неймана оказы¬ 
вается плохим средством для выполнения программ, написан¬ 
ных на языках высокого уровня, по следующим причинам: 

1. Чрезмерный расход программных средств (например, ра¬ 
бота компилятора по формированию машинных кодов) с целью 
согласования возможностей языка со структурой памяти по 
фон Нейману, что трактуется как «абсорбирование структуры 
(данных) в логике программы» [19]. Это становится очевидным 
каждому, анализирующему результат работы компилятора: 
объем машинных кодов, генерируемых компилятором с целью 
отражения языковой концепции памяти и данных в архитектуре 
используемой машины, обычно значительно превосходит объем 
подобных кодов, предназначенных непосредственно для реше¬ 
ния поставленной задачи. 

2. Машина фон Неймана — чрезмерно универсальна. Так, 
можно использовать слово, значение которого для текущего мо¬ 
мента не определено, адресоваться к чему угодно в памяти, 
складывать строку символов с командой. А поскольку подобная 
универсальность отсутствует в языках программирования, на 
компилятор (и генерируемый им код) возлагается задача уст¬ 
ранения универсальности и обеспечения отсутствия искажений, 
которую она может внести в определение языка. 

3. В силу относительной примитивности принципа организа¬ 
ции памяти по фон Нейману операции (набор команд), выпол¬ 
няемые машиной, оказываются в равной мере примитивными. 

Подобно другим первенцам науки и техники, таким, как 
электромеханические реле и электровакуумные лампы в логиче¬ 
ских схемах, логарифмическая линейка, теория строения ато¬ 
ма Н. Бора, перфоратор, архитектура ЭВМ фон Неймана со¬ 
служила добрую службу человечеству и к настоящему времени 
изжила себя. Требования к вычислительным системам достиг¬ 
ли высокого уровня сложности, причем их большая часть со¬ 
средоточена на комплексе программных средств. Стремление 
к удовлетворению постоянно растущих требований заставляет 
«архитектора» вычислительных систем совершенствовать взаи¬ 
мосвязь архитектуры машины с программным обеспечением, 
т. е. улучшать архитектуру машины таким образом, чтобы она 
лучше согласовывалась с программными средствами. 

Прежде чем завершить обсуждение архитектуры фон Ней¬ 
мана, отметим, что структура современных языков программи¬ 
рования имитирует основные принципы организации машины 
фон Неймана в виде арифметического устройства, устройства 
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управления и памяти [20]. Так, переменная имитирует пассив¬ 
ное запоминающее устройство, оператор присваивания — ариф¬ 
метическое устройство, последовательное выполнение операто¬ 
ров управления (таких, как GO ТО, IF) — устройство управ¬ 
ления. Более подробно об этом речь идет в гл. 22. 

ДОПОЛНИТЕЛЬНЫЕ ПРИЧИНЫ 
СЕМАНТИЧЕСКОГО РАЗРЫВА 

Хотя основной вклад в наличие семантического разрыва вносит 
сама модель машины фон Неймана, дополнительным источни¬ 
ком причин этого разрыва являются некоторые характеристики 
архитектуры современных вычислительных систем. 

двоичная арифметика 

В современных машинах место двоичной арифметики, можно 
сказать, священно, несмотря на то что человек воспринимает 
ее почти во всех случаях с определенным чувством неприязни. 
Можно спорить относительно того, является ли это следствием 
определенной культуры, присуще ли это природе человека или 
порождено математикой. Но факт неприятия человеком двоич¬ 
ной арифметики налицо. Поскольку предложение перехода к 
десятичной арифметике часто вызывает горячие споры, небес¬ 
полезно проанализировать все «за» и «против». 

Два довода можно привести в пользу десятичной арифмети¬ 
ки. Первый из них основан на том обстоятельстве, что в на¬ 
стоящее время применение ЭВМ сопряжено с большим объе¬ 
мом работ по организации ввода-вывода. А поскольку найдет¬ 
ся немного сторонников выполнения этих работ с использова¬ 
нием представления чисел в двоичной системе счисления, то 
современные вычислительные системы вынуждены затрачивать 
огромное количество времени на десятично-двоичные преобра¬ 
зования. (Предвидя это, фон Нейман справедливо полагал, что 
пользователи ЭВМ изъявят желание воспользоваться восьме- 
и шестнадцатеричными системами счисления [18].) 

Второй из упомянутых выше доводов в пользу десятичной 
системы счисления базируется на следующем. От пользователя 
ЭВМ не удается полностью скрыть тот факт, что числа внутри 
машины представлены в двоичной форме, поскольку, например, 
дробные части вещественных чисел представляются как беско¬ 
нечные дроби двоичной системы счисления. Это означает, что 
двоичные числа конечной длины — часто лишь аппроксимации 
десятичных чисел и, как следствие, причина затруднений при 
программировании, источник ошибок в программе и некоррект¬ 
ности некоторых формальных определений синтаксиса языка 
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программирования. Вот, например, к каким последствиям это» 
приводило при использовании бортовых ЭВМ при полетах аме¬ 
риканских космических кораблей по программе «Аполлон». При- 
вводе данных в машину посредством клавиатуры ЭВМ должна; 
воспроизводить вводимые данные на экране дисплея в целях- 
визуального контроля. В руководстве оператора для подобного, 
случая имелось следующее предупреждение: «Не следует бес¬ 
покоиться, если воспроизводимые на экране данные отличаются- 
от вводимых с клавиатуры цифрой младшего разряда, посколь¬ 
ку ЭВМ выполняет вычисления посредством двоичной арифме* 
тики». 

Несмотря на то что при создании языка Ада обращалось, 
особое внимание на проблемы точности вычислений и портатив¬ 
ности программы (простоты переноса программы из одной вы¬ 
числительной среды в другую), операции этого языка над дан^ 
ными вещественного типа (числами с фиксированной или пла¬ 
вающей точкой) выполнимы только при наличии в машине дво¬ 
ичной арифметики, а следовательно, заведомо предполагается 
аппроксимация числовых данных (хотя и при наличии средств 
управления ошибкой аппроксимации). По традиции програм¬ 
мисты проявляют определенную осторожность при использова* 
нии данных в форме с плавающей точкой, и все же многих 
шокирует то обстоятельство, что арифметика с плавающей 
точкой неизбежно сопряжена с аппроксимацией числовых дан¬ 
ных. В то же время, например, в языках ПЛ/1 и КОБОЛ для 
десятичных чисел арифметика с фиксированной точкой выполт- 
няется точно. 

При реализации в языке Ада определения 

type UNIT-PRICE is delta 0.01 range 0.00...500.00; 

переменные этого типа могут быть представлены как 16-разряд- 
ные целые двоичные числа, причем каждое приращение (ин¬ 
тервал) равно 0.0078125. Описания и оператор присваивания- 

PAPER _ COST : UNIT-PRICE : = 0.30; 

TOTAL-COST: UNIT -PRICE; 

TOTAL-COST: = PAPER-COST. 10; 

присваивают переменной TOTAL—COST значение 2.97 или 3.05 
(в зависимости от той или иной реализации языка); потери 3 
или 5% являются неприемлемыми. 

Традиционными аргументами против десятичной арифмети¬ 
ки являются следующие: она уступает в быстродействии двоич¬ 
ной арифметике; двоичные числа можно хранить в более ком¬ 
пактной форме, чем десятичные. Но эти доводы подлежат об¬ 
суждению. Во-первых, при оценке скорости выполнения ариф^ 
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метических операций следует учитывать необходимость 
предварительного преобразования десятичных чисел в дво¬ 
ичные и последующего обратного преобразования. Во-вто¬ 
рых, разработаны схемы выполнения операций десятичной 
арифметики (например, [21]), быстродействие которых может j 
конкурировать с быстродействием схем двоичной арифметики; 
первые незначительно уступают последним только по показа¬ 
телю стоимости. Новые быстродействующие большие инте¬ 
гральные схемы (БИС) на основе логических схем со связан¬ 
ными эмиттерами, предназначенные для выполнения арифмети¬ 
ческих операций, способны оперировать двоично-кодированной 
десятичной информацией с той же скоростью, что и БИС 
двоичной арифметики [22]. 

Второй аргумент против десятичной арифметики (неэконом¬ 
ное использование пространства памяти) более существенный, 
но и его нельзя считать непреодолимым. Одним из путей реше¬ 
ния этой проблемы можно считать применение представления 
чисел, отличного от двоично-кодированного десятичного. Если | 
вместо основания 10 использовать основание 100, то для хране¬ 
ния двух десятичных цифр окажется достаточным иметь семь 
двоичных разрядов вместо восьми [23]. Переход к основанию ! 
1000 позволяет размещать три десятичные цифры в 10 двоич- 5 
ашх разрядах вместо 12. Подобное представление десятичных 
чисел для арифметики с плавающей точкой предлагалось и 
фанее [24]. 

РЕГИСТРЫ 

Использование программно-адресуемых регистров, получивших 
название регистров общего назначения, является еще одной 
концепцией архитектуры современных вычислительных систем, 
чуждой принципам языков программирования. Обычно эти ре¬ 
гистры определяются следующими характеристиками: 

1) предназначены для формирования самостоятельного ад¬ 
ресного пространства, отличного от адресного пространства ос- і 
«овной памяти ЭВМ; 

2) ограниченным количеством (например, в машине может 
■быть предусмотрено 8 или 16 регистров); 

3) фиксированным количеством двоичных разрядов регист¬ 
ра (16 или 32 разряда); 

4) адресуются посредством коротких адресов; 

5) адресуются за более короткое время, чем подобные эле¬ 
менты основной памяти; 

6) управляются программными средствами при выполнении 
всех процедур и вычислительных процессов, являясь тем самым 
единственным подобным ресурсом системы; 
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7) функционально специализированы до определенной сте¬ 
пени. (Это означает, что при реализации некоторых конкрет¬ 
ных функций требуется использование регистров, иногда вполне 
определенных.) 

Принцип использования программно-адресуемых регистров 
плохо согласуется со структурой организации данных в совре¬ 
менных языках программирования и влечет за собой следую¬ 
щие проблемы: 

1. Слишком частое использование команд LOAD (ЗАГРУЗ¬ 
КА В РЕГИСТР) и STORE (ЗАПИСЬ В ПАМЯТЬ). Во многих 
вычислительных системах, использующих регистры общего наз- 
начения (Система 370, PDP-11), арифметические операции и 
операции адресации могут быть выполнены только посредством: 
этих регистров. Поток команд подобных вычислительных си¬ 
стем изобилует командами LOAD и STORE, вследствие чего 
возрастает размер программ и снижается скорость их выпол¬ 
нения. Об этом речь пойдет далее в этом разделе, а также 
в гл. 4. 

2. Неэффективность процедур сохранения и перезагрузки 
содержимого регистров при обращениях к подпрограммам. На¬ 
бор регистров — единственный ресурс вычислительной системы, 
содержимое которого частично или полностью подлежит сохра¬ 
нению при вызове подпрограмм и обработке прерываний с по¬ 
следующей перезагрузкой этого содержимого при возврате к вы¬ 
зывавшему программному модулю или модулю, выполнение 
которого прерывалось. В дополнение к этому можно заметить,, 
что управление регистрами посредством программных средств 
приводит к выполнению многих ненужных операций сохранения 
и перезагрузки их содержимого. Часто стратегия управления 
такова, что та или иная подпрограмма предполагает сохранение 
и восстановление содержимого тех конкретных регистров, кото¬ 
рые ею используются. Поскольку подпрограмма «не знает», как 
эти регистры используются программными модулями, ее вызы¬ 
вающими, возможно выполнение сохранения и восстановления 
содержимого регистров, которыми указанные программные мо¬ 
дули не пользуются. Нерациональность сохранения и переза¬ 
грузки содержимого регистров проявляется и при повторении 
последовательности обращений к подпрограммам, например к 
трем подпрограммам А, В и С. Когда выполняется возврат из 
подпрограммы А, содержимое регистров восстанавливается 
только для того, чтобы вновь быть загруженным подпрограм¬ 
мой В на сохранение, и т. д. Подобные непроизводительные 
операции имеют место и при работе с набором вложенных под¬ 
программ: подпрограмма D возвращает управление подпро¬ 
грамме С, которая тотчас же возвращает управление подпро¬ 
грамме В, последняя сразу же возвращает управление под-. 
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шрограмме А и т. д. При возвращении управления каждая 
«подпрограмма восстанавливает содержимое регистров, и при 
этом большая часть этой работы оказывается совершенно не¬ 
нужной. 

3. Потеря общности принципов программирования. Имеются 
в виду некоторые проблемы программирования и организации 
работы компилятора, возникающие вследствие различия ме¬ 
ханизма адресации регистров и памяти. В качестве примера 
„рассмотрим подпрограмму, получающую некоторый параметр 
при адресации к ней. Если данная подпрограмма вызывается 
другой подпрограммой, использующей в качестве этого пара¬ 
метра локальную переменную, то необходимо либо отказаться 
от хранения локальной переменной в регистре (что может быть 
нежелательным при частом ее использовании), либо хранить 
эту переменную в регистре, помещать ее на временное хранение 
в память перед вызовом подпрограммы, передавать адрес об¬ 
ласти временного хранения и загружать ее обратно в регистр 
после возврата из подпрограммы. 

4. Проблемы программирования. Они обусловлены тем, что 
широко используемые регистры общего назначения представля¬ 
ют собой память, структура которой отлична от структуры ос¬ 
новной памяти вычислительной системы. Если последняя обыч¬ 
но имеет побайтовую адресацию, то к регистрам адресуются 
как к словам (регистр — это запоминающее устройство объе¬ 
мом, как правило, 16 или 32 бит). Все благополучно до тех пор, 
пока объем данных совпадает с емкостью регистров. Последние 
бесполезны или почти бесполезны, когда необходимо манипули¬ 
ровать битами, байтами, цепочками символов и т. п. Регист¬ 
ры — неотъемлемый ресурс программистов и разработчиков 
компиляторов, а поэтому и те и другие должны владеть техни¬ 
кой манипуляции этим ресурсом. Ошибки при работе с регист¬ 
рами часто ведут ксзагадочным» ошибкам. Поскольку механизм 
функционирования регистров носит специальный характер, у 
программиста возникают дополнительные трудности. Например, 
яри работе с микропроцессором Motorola 68000 индексирование 
можно выполнить только посредством адресных регистров. Бо¬ 
лее того, многие операции этой машины осуществимы только 
при участии регистров данных, а не адресных регистров. В Си¬ 
стеме 370 некоторые операции определены только для операн¬ 
дов, размещаемых в регистрах, другие — для операндов как 
хранимых в памяти, так и загруженных в регистры, и, наконец, 
имеются операции, выполняемые только над данными в основ¬ 
ной памяти. 

5. Проблемы отладки. Регистры часто используются для 
размещения локальных и временных переменных. Если про¬ 
грамма прервана или каким-либо иным способом остановлена 
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в процессе выполнения, программист не всегда способен иден¬ 
тифицировать точное состояние программы. 

6. Сложность архитектурных решений. Порождается специ¬ 
фикой средств адресации и функционирования регистров. А по¬ 
скольку последние — неотъемлемая часть процессора, возникает 
неизбежное переплетение различных архитектурных решений 
в рамках единой вычислительной системы. 

После этих критических замечаний небесполезно проанали¬ 
зировать исходные доводы в пользу регистров общего назначе¬ 
ния. Во-первых, их введение преследовало цель сокращения 
размера программ. Адреса регистров обычно меньше адресов 
основной памяти, и, как следствие, команды, манипулирующие 
содержимым регистров, компактнее команд, адресующихся к 
памяти. Во-вторых, поскольку регистры выполняются на эле¬ 
ментах памяти повышенного быстродействия, предполагалось 
достижение большей скорости выполнения операций. 

Упомянутое сокращение размера программ — спорный во¬ 
прос. Во-первых, необходимо найти определенный баланс меж¬ 
ду возможностью использования более коротких команд и со¬ 
путствующей потребностью в дополнительных командах по пе¬ 
ремещению данных из регистров в память и обратно (команды 
LOAD и STORE). Анализ программ, написанных на различных 
языках программирования для ЭВМ PiDP -ІО, показывает, что 
42% всех выполняемых команд затрачивается на перемещение 
данных между памятью и регистрами [5, 25]. Исследование 
возможностей оптимизирующих компиляторов для семейств 
ЭВМ PDP-11 и CDC 6000 свидетельствует о незначительном 
влиянии на размер программ сокращения числа регистров [26, 
27]. Во-вторых, в современных машинах форма адресации па¬ 
мяти носит слишком общий характер и не имеет тесной взаимо¬ 
связи со средствами адресации, используемыми программами. 
Совершенствование механизма адресации (см. гл. 4) может 
привести к сокращению в командах размера адреса памяти, что 
в свою очередь снижает эффективность использования регист¬ 
ров в целях подобного сокращения. 

Следует обсудить и второй довод в пользу введения регист¬ 
ров — достижение большей скорости выполнения команд. И в 
этом случае необходим определенный компромисс между полу¬ 
чением более быстрого доступа к данным в регистрах и сопут¬ 
ствующим требованием заблаговременного извлечения и деко¬ 
дирования команд перемещения данных между регистрами и 
памятью. Объем работ по такому извлечению и декодирова¬ 
нию команд может оказаться значительным (42% от общего 
объема команд согласно упомянутому выше исследованию). 
Иллюстрацией сказанного может служить и табл. 2.1, которая 
содержит сведения о количестве различных команд небольшой 




Таблица 2.1. Некоторые статистические сведения о командах программы, 
выполненной Системой 370 
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программы на языке ПЛ/1 для Системы 370. Команды располо¬ 
жены в порядке убывания частоты их использования и их 
вклада в значение параметра М. 

Они могут быть разделены на две группы: команды, выпол¬ 
няющие работу согласно алгоритму решаемой задачи, и коман¬ 
ды подготовки к подобной работе. К последним можно отнести 
все команды загрузки регистров и записи их содержимого в па¬ 
мять, а также все команды перехода (единственное назначение 
которых — изменение содержимого счетчика команд). При 
рассмотрении программы с такой точки зрения оказывается, что 
65% команд выполнения операций и 69% команд перемещения 
данных между процессором и памятью — это команды подго¬ 
товки к выполнению работ, предписываемых алгоритмом исход¬ 
ной задачи. Подобная статистика не является нетипичной. Бо¬ 
лее обширные исследования программирования в Системе 370 
[7] показывают, что удельный вес подобных команд в програм¬ 
ме достигает 70,1 %. 

Для более детального знакомства с использованием регист¬ 
ров можно рекомендовать исследования А. Лунде [5, 25], де¬ 
монстрирующие ряд программ и компиляторов, выполняемых 
на машине с регистрами. Одним из выводов этих исследований 
является утверждение, что для машины с 16-разрядными ре¬ 
гистрами общего назначения среднее число задействованных 
регистров (т. е. таких, в которых что-либо содержится в данный 
момент или будет находиться в ближайшем будущем) состав¬ 
ляет только 3,9. Другой вывод сводится к тому, что значитель¬ 
ное сокращение числа регистров в машине оказывает несущест¬ 
венное влияние на скорость выполнения программы. 

Эффект высокой скорости регистровых операций снижается 
стремлением современного программирования к достижению 
максимальной модульности комплекса программ, приводящей 
к дроблению каждой программы на большое количество отдель¬ 
но компилируемых подпрограмм. Это обстоятельство оказывает 
двоякое воздействие на использование регистров. Во-первых, 
уменьшается эффект оптимального использования регистров, на 
достижение которого ориентирована работа компилятора. 
Во-вторых, наличие большого количества программных модулей 
влечет за собой увеличение частоты операций загрузки регист¬ 
ров и записи их содержимого в память (как следствие, напри¬ 
мер, необходимости перехода от одного программного модуля 
к другому). 

Отметим, что даже при отказе от использования регистров 
общего назначения, возможно достижение любого быстродей¬ 
ствия, обеспечиваемого их применением. Так, реализация прин¬ 
ципа кэш-памяти позволяет получить такую же высокую ско¬ 
рость доступа к данным, которую обеспечивают регистры, и из- 
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бежать при этом большинства проблем, упомянутых выше. 
Дальнейшему анализу архитектуры вычислительной машины,, 
в которой используются регистры общего назначения, посвяще¬ 
на гл. 4. 


УПРАЖНЕНИЯ 

2.1. Назовите пять характеристик массивов (таблиц данных) в языке 
ПЛ/1 и детально поясните причины семантического разрыва между соответ¬ 
ствующей структурой языка и организацией памяти машины фон Неймана. 

2.2. Хотя в данной главе и проводится идея о необходимости сокраще¬ 
ния семантического разрыва, на практике существуют пределы такого сокра¬ 
щения. Какая может возникнуть основная проблема при значительном сокра¬ 
щении семантического разрыва? 

2.3. Несмотря на то что еще не были сформулированы архитектурные 
принципы сокращения семантического разрыва, перечислите четыре характе¬ 
ристики машины фон Неймана и применительно к каждой из них укажите 
соответствующие меры возможного сокращения семантического разрыва. 

2.4. Почему в большинстве языков программирования на современных 
машинах 1,0 редко равна 10,0X0,1? 

2.5. Насколько менее эффективно кодирование десятичных цифр четырь¬ 
мя битами по сравнению с -использованием двоичной системы счисления? 

2.6. Прокомментируйте целесообразность построения машины с набора¬ 
ми регистров общего назначения — один набор для каждого вычислительного 
процесса или уровня прерываний — при условии, что преследовалась цель со¬ 
кращения действий по загрузке и запоминанию содержимого регистров при 
переходе от одного процесса (процедуры) к другому. 

2.7. Для программы, представленной в табл. 2.1, вычислите отношение- 
числа. загрузок регистров (предположим, при использовании команд L, LH, 
LM, LA, LR) к числу обращений к содержимому регистров, исключая опера¬ 
ции записи в память (например, две в команде AR или CR, одна в команде 
А или BCR). (Пренебрегите использованием регистров базы для переопреде¬ 
ления местоположения программы; считайте, что в этой программе никакие 
операции с индексными регистрами не выполняются.) 

2.8. Возьмите программу средних размеров (или несколько небольших 
примеров фрагментов программ) и проведите количественный анализ по ис¬ 
пользованию языковых конструкций. Важной является статистика по исполь¬ 
зованию декларативных и императивных операторов, различных типов дан¬ 
ных, сложности выражений и среднего числа обращений к каждой перемен¬ 
ной. 

2.9. Рекомендуется прочесть оригинальную статью фон Неймана о маши¬ 
не с запоминаемой программой (она включена как гл. 4 в книгу Белла и- 
Ньюэла і[2в] ). В этой статье обсуждаются некоторые из проблем, упомяну¬ 
тых в настоящей главе, и объясняется, почемѵ пришлось идти на те ил» 
иные компромиссы. 
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ГЛАВА 3 

ПРИВЯЗКА ПРОГРАММ К МАШИНАМ 


Возможные пути сокращения семантического разрыва между 
языком программирования и машиной отличаются друг от дру¬ 
га тем, как и за какое время осуществляется так называемая 
привязка программы к машине, на которой программа должна 
выполняться. Привязку можно определить как процесс допол¬ 
нения и модификации программы посредством информации, поз¬ 
воляющей выполнять программу на выбранной машине [1]. 
Привязку можно также рассматривать как выбор определенных 
характеристик программы из некоторого набора возможных 
характеристик. 

Процесс осуществления привязки можно обсуждать в двух 
аспектах: временном и информационном. Временной аспект 
характеризует период времени между написанием программы и 
выполнением отдельного оператора этой программы. Информа¬ 
ционный аспект отображает типы информации, используемые 
при выполнении привязки, и включение описания параметров 
данных, их значений и местоположения. 

В случае привязки конкретного оператора программы к ти¬ 
повой вычислительной системе временной аспект может охва¬ 
тывать следующие моменты: 1) привязку в процессе написания 
оператора; 2) привязку в процессе компилирования; 3) при¬ 
вязку в процессе установления связей с подпрограммами (на¬ 
пример, на этапе, называемом «редактирование и установление 
связей»); 4) привязку в процессе загрузки программы; 5) при¬ 
вязку в процессе вызова подпрограммы; 6) привязку в процес¬ 
се выполнения предыдущего оператора программы; 7) привязку 
в процессе выполнения данного оператора. 

Привязка в процессе написания оператора предполагает 
принятие решений, которые в дальнейшем не могут быть изме¬ 
нены. Например, при записи оператора 

А:=А+3; 
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осуществлена привязка к значению 3. Если же используется 
оператор 
A:=A+N; 

то указанной выше привязки не происходит, значение перемен¬ 
ной N в дальнейшем можно изменять. Если в процессе написа¬ 
ния программы программист включает в ее текст информацию, 
зависящую от специфических характеристик машины, то проис¬ 
ходит привязка программы к машине. Одним из главных отли¬ 
чий программ на языках высокого уровня от программ на язы¬ 
ках ассемблера является значительно большая степень привяз¬ 
ки последних к машине уже на этапе их написания. 

В большинстве традиционных вычислительных систем при¬ 
вязка программы к машине осуществляется в значительной сте¬ 
пени на этапе компилирования, когда идентификаторы перемен¬ 
ных преобразуются в адреса, а операторы программы — в по¬ 
следовательности машинных команд. В машине с традиционной 
архитектурой фон Неймана привязка всех атрибутов (опреде¬ 
лителей данных) обычно выполняется именно на этом этапе. 
Например, при компилировании оператора 
А:=А+1 

компилятор принимает решение, каким — двоичным, с плаваю¬ 
щей точкой или десятичным — должно быть сложение и какова 
точность этой операции. В первых вычислительных системах 
компиляторы создавали абсолютные (неперемещаемые) объект¬ 
ные программы, предопределяя тем самым привязку местополо¬ 
жения программы (назначение программе конкретных адресов 
памяти) на этапе компилирования. 

Системы с отдельным этапом установления связей с под¬ 
программами предполагают осуществление определенного вида 
привязки не ранее выполнения этого этапа. Например, подпро¬ 
грамма может содержать обращение к другой подпрограмме X, 
и привязка первой подпрограммы к упомянутой подпрограм¬ 
ме X может быть отнесена на время, следующее за этапом ком¬ 
пилирования. 

Дальнейшая привязка, обычно связанная с указанием место¬ 
положения, происходит во время загрузки программы. В зави¬ 
симости от специфики вычислительной системы на этапе загруз¬ 
ки программы может происходить полная привязка последней 
к определенной области памяти без возможности дальнейшего 
ее перемещения в памяти или частичная привязка, допускаю¬ 
щая последующее перемещение. 

В зависимости от специфики программы, вычислительной 
системы и языка программирования привязка определенного 
вида может быть отложена до тех пор, пока в процессе выпол- 
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нения программы не произойдет вызов требуемой подпрограм- 
мы. Если в языке программирования предусмотрена возмож¬ 
ность использования локальных переменных, местоположение 
последних устанавливается как раз в это время. При передаче 
параметров в подпрограмму их привязка к конкретным значе¬ 
ниям осуществляется именно на этапе вызова подпрограммы. 
(Некоторые особенности средств передачи параметров в под¬ 
программу, такие, как передача параметров по имени, позволя¬ 
ют отложить привязку рассматриваемого вида даже на более 
поздний период.) 

Ряд параметров программы делает возможным отложить 
привязку определенного вида до момента выполнения первого 
оператора программы. Например, оператор 

А (I): = В; 

оказывается связан с определенным адресом области памяти 
только после выполнения некоторого предшествующего опера¬ 
тора, задающего значение переменной I. В определении 

BUFFER : access STRING; 

языка Ада местоположение цепочки STRING и ее размер ока¬ 
зываются заданными (привязанными к вычислительной систе¬ 
ме) только после того, как некоторый оператор присвоит пере¬ 
менной BUFFER определенное значение. 

Наконец, все привязки, имеющие отношение к некоторому 
оператору, не выполненные на предыдущих этапах, подлежат 
реализации в процессе выполнения этого оператора программы. 

Итак, многие свойства современных языков программирова¬ 
ния, операционных систем, архитектуры вычислительных машин 
отдаляют процесс привязки программы к машине на все более 
поздние этапы подготовки программы и ее выполнения. Как 
упоминалось выше, при использовании языков высокого уровня 
объем работ по привязке, выполняемой программистом на этапе 
написания программы, сокращается. Применение индексных ре¬ 
гистров и косвенной адресации позволяет отложить привязку 
команды к объекту с конкретным местоположением до начала 
выполнения программы. Использование в языке ПЛ/1 символа 
«звездочка» для указания длины строки или размерности пере¬ 
менной, а в языке Ада нелимитированных формальных парамет¬ 
ров дает возможность отложить процесс привязки операторов 
программы к определенным значениям аргументов подпрограм¬ 
мы до момента обращения к ней. Виртуальная память позволя¬ 
ет осуществлять привязку ее адресов к физическим адресам 
операндов команды не ранее начала выполнения последней. 
Процедура открытия файла предоставляет возможность не наз- 
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начать программе конкретный файл вплоть до начала ее вы¬ 
полнения. 

Итак, наблюдается тенденция к задержке процесса привяз¬ 
ки программ к конкретным описаниям параметров данных, их.' 
значений и местоположения. Главное достоинство этого явле¬ 
ния состоит в определенной гибкости работы программиста,, 
благодаря чему программа носит более обобщенный характер' 
в течение большего периода времени. (Исключением является 
язык Ада, в котором значительный объем операций по привяз¬ 
ке перенесен обратно на этап компилирования, поскольку в про¬ 
цессе разработки языка было сделано заключение о том, что^ 
машины с традиционной архитектурой не обеспечивают в до¬ 
статочной степени сохранность программ.) 

Согласно изложенному в гл. 2, архитектура машины фон. 
Неймана способствует перемещению основного объема работ по- 
привязке программы к машине на этап компилирования (на¬ 
пример, это определяется как «абсорбирование структуры и ха¬ 
рактеристик данных в логике работы программы»). Отсюда, 
следует, что усилия по сокращению семантического разрыва 
между языком программирования и машиной требуют форму¬ 
лировки принципов переноса части или всего объема работ по. 
привязке программы к машине на более поздние этапы, вплоть 
до этапа выполнения программы. Прежде чем перейти к де¬ 
тальному рассмотрению этих принципов (гл. 4), обсудим в дан¬ 
ной главе некоторые основные подходы к решению проблемы 
упомянутого семантического разрыва, приведя по каждому из* 
этих подходов соответствующие литературные источники. Дан¬ 
ный обзор ограничен только проблемой семантического разры¬ 
ва между языком программирования и машиной. 

Рис. 3.1 может помочь сформулировать некоторые из основ¬ 
ных подходов к определению архитектуры вычислительной ма¬ 
шины. Ветвь 1 символизирует традиционный подход: посредст¬ 
вом обширного процесса компилирования программа на языке 
высокого уровня переводится в программу на машинном языке, 
которая затем интерпретируется машиной. Первая разновид¬ 
ность архитектуры, ориентированной на сокращение семантиче¬ 
ского разрыва между языком программирования и машиной,, 
представлена ветвью 2: исходная программа компилируется в; 
программу на машинном языке более высокого уровня; послед¬ 
няя подлежит интерпретации машиной. Архитектура вычисли¬ 
тельных систем такого типа известна под названием архитекту¬ 
ры, ориентированной на язык высокого уровня. 

Ветви 3 и 4 на рис. 3.1 символически представляют три архи¬ 
тектурных решения; соответствующие вычислительные машины* 
имеют общее наименование машин языков высокого уровня . 
Машины с архитектурой, представленной ветвью 3, достигают 



ГЛАВА 3 


такого уровня, когда язык высокого уровня можно рассматри¬ 
вать как язык ассемблера. Говоря иначе, есть взаимно-одно¬ 
значное соответствие типов операторов и знаков операций язы¬ 
ка высокого уровня с командами машинного языка. В данном 
случае правильно говорить об ассемблировании, а не о компи- 



ВетВь 4 


Фис. 3.1. Взаимосвязь между программами на языке высокого уровня 
« на машинном языке. 

лировании исходной программы. Ветвь 3 представляет две раз¬ 
новидности архитектуры, в одной из которых ассемблирование 
выполняется программными, а в другой аппаратными средства¬ 
ми. Архитектура, соответствующая ветви 4, отличается тем, что 
здесь язык высокого уровня является также и машинным язы¬ 
ком; машина интерпретирует непосредственно программу на 
языке высокого уровня. 

АРХИТЕКТУРА, ОРИЕНТИРОВАННАЯ 
'НА ЯЗЫК ВЫСОКОГО УРОВНЯ 

Речь идет о машинах, организация данных и набор операций 
которых по структуре значительно теснее связаны с организа¬ 
цией данных и набором операций одного или нескольких язы¬ 
ков высокого уровня. Указанное выше название архитектуры 
таких машин не является ни строгим по определению, ни обще¬ 
принятым, что, впрочем, характерно для большинства терминов 
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вычислительной техники. Например, если к набору команд. 
Системы 370 добавить команду, семантически подобную опера¬ 
тору языка КОБОЛ PERFORM-UNTIL, архитектура этой вы¬ 
числительной системы стала бы в большей степени ориентиро¬ 
вана на язык программирования, однако этого недостаточно*» 
для классификации ее как архитектуры, ориентированной наг 
язык высокого уровня. Последняя предполагает, что соответ¬ 
ствующая ей машина проектируется с оказанием требованиям» 
одного или нескольких языков высокого уровня явного приори¬ 
тета перед другими возможными требованиями. 

Термин «архитектура, ориентированная на язык высокого» 
уровня» впервые, по-видимому, ввел У. Мак-Кимен [2], хотя- 
архитектуру этого типа анализировали и другие ученые [3, 4]. 
К вычислительным системам, ориентированным, например, на? 
АЛГОЛ, относятся системы В5500/6500/6700/7600 фирмы Bur¬ 
roughs [5, 77], KDF.9 [6] и MU5 [7]. Предпринимались также» 
попытки разработать архитектуру, в которой были бы отраже¬ 
ны некоторые общие характеристики языков с блочной структу¬ 
рой [3, 8—11]. Разработана машина с архитектурой, ориенти¬ 
рованной на язык TPL с блочной структурой и операциями, по¬ 
добными тем, которыми располагает язык APL [12]. 

L -машина имеет архитектуру с традиционной организацией:* 
памяти, однако набор ее команд ориентирован на язык ПЛ/1 
[13, 14]. Эта архитектура была реализована на машине с мик¬ 
ропрограммным управлением Microdata 1621. Пример другой? 
машины, ориентированной на язык ПЛ/1, описан в работе Су- 
гимото [15]. На диалект подмножества языка ПЛ/1 ориентиро¬ 
вана учебная ПЛ-машина, рассматриваемая во второй части- 
дэнной книги [16]. 

ЭВМ В3500 фирмы Burroughs является ориентированной на- 
КОБОЛ машиной, предназначенной для финансово-экономиче¬ 
ских расчетов; фирма NCR Criterion недавно разработала два* 
архитектурных решения машины: традиционное и ориентиро¬ 
ванное на КОБОЛ [17, 18]. Переход от одной архитектуры к: 
другой выполняется динамически, под управлением средств- 
взаимосвязи подпрограмм. Исследования показывают, что про¬ 
граммы на КОБОЛе, компилируемые в расчете на архитектуру,, 
ориентированную на КОБОЛ, выполняются в четыре раза быст¬ 
рее, чем в случае их компилирования для традиционной архи¬ 
тектуры. В литературе [19—21, 78, 80] описывается несколько* 
экспериментальных машин, архитектура которых также ориен¬ 
тирована на КОБОЛ. 

Поскольку в настоящее время вызывает интерес язык Пас¬ 
каль, не удивительно, что появляются экспериментальные ма¬ 
шины с архитектурой, ориентированной на этот язык [22, 79— 
81]. Одна из них выполнена на микропроцессорах, производи»- 
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мых фирмой Western Digital. То же самое можно сказать и 
*в отношении языка ЛИСП. В Массачусетском технологическом 
институте разработан проект машины CONS с архитектурой, 
ориентированной на язык ЛИСП [23, 24]; машина предназна¬ 
чена для использования в том же институте. Кроме того, было 
разработано по крайней мере два варианта машин с архитек¬ 
турой подобной ориентации [25—27]. Несколько небольших 
“фирм сообщили о том, что располагают возможностями начать 
с 1981 г. производство машин с архитектурой, ориентированной 
на язык ЛИСП, которые предназначены для ведения финансо¬ 
во-экономических расчетов. 

Для создания машин языков высокого уровня и машин, 
ориентированных на языки программирования, широко исполь¬ 
зуется язык APL. Так, машина Raytheon AADC ориентирована 
на язык APL [28, 29]. То же можно сказать и о ЭВМ STARLET 
с экспериментальной архитектурой, располагающей мощными 
средствами по структурированной организации данных [30, 31]. 
Авторы работы [32] сообщают об архитектуре, предоставляю¬ 
щей возможность управления программными средствами кон¬ 
фигурацией аппаратных ресурсов вычислительной системы. Эта 
архитектура предусматривает набор операций, подобный тому, 
которым располагает язык APL. Опубликованы сведения о 
проектах машин с архитектурой, ориентированной на языки 
Balm [33], Магу [34], Snobol [35], на расширенную версию 
■языка CLU [36], не имеющий названия алгоритмический язык 
£37], язык HLAX [82] и язык реального времени [83]. 

Иным подходом к созданию машин подобной архитектуры 
■является ориентация последней не на один конкретный язык, 
-а «а общие семантические характеристики некоторой группы 
•языков. Примерами подобных решений могут служить вычисли¬ 
тельные машины Rice Research Computer [38], BLM [39] и др. 
[40—44]. Разработчики машины SWARD [45], описываемой в 
части V книги, не стремились к созданию архитектуры, ориен¬ 
тированной на определенный язык высокого уровня, а пытались 
построить машину, обеспечивающую программисту благоприят¬ 
ную рабочую среду. В результате таких усилий была сконструи¬ 
рована машина с архитектурой, ориентированной на языки 
.Ада, ПЛ/1, Фортран, Кобол и т. п. Другим примером такого 
оюдхода является машина іАРХ 432 фирмы Intel, рассматри¬ 
ваемая в части VI книги. Архитектура этой машины до некото¬ 
рой степени ориентирована на язык Ада. 

Промежуточное положение между двумя указанными подхо¬ 
дами к ориентации архитектуры машины на языки программи¬ 
рования (ориентация на конкретный язык или на обобщенные 
свойства языков) занимает описываемая в части IV архитектура 
машины В1700 фирмы Burroughs. В процессе работы машины 
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посредством вызова различных микропрограмм можно динами¬ 
чески переходить от одного набора команд к другому, ориенти¬ 
руя тем самым архитектуру машины на тот язык, на котором 
написана подлежащая выполнению программа. 


АРХИТЕКТУРА МАШИН 

ЯЗЫКОВ ВЫСОКОГО УРОВНЯ. ТИП А 

Теперь перейдем к рассмотрению архитектуры, соответствую¬ 
щей ветви 3 на рис. 3.1. В указанном случае архитектура ма¬ 
шины должна быть ориентирована на язык высокого уровня до 
такой степени, когда последний воспринимается как язык ас¬ 
семблера (машинный язык в символической форме). Иначе го¬ 
воря, при этом должно быть однозначное соответствие между 
типами операторов и знаками операций языка высокого уровня, 
с одной стороны, и машинными операциями — с другой. Тогда 
программа, преобразующая исходную программу в программу 
на машинном языке и обычно называемая компилятором, полу¬ 
чает более точное наименование — ассемблер. Она убирает из 
исходной программы комментарии и пробелы, преобразует зна¬ 
ки операций, разделители и ключевые слова в более короткие 
машинные коды, имена переменных — в адреса, реорганизует, 
если это необходимо, выражения из инфиксной формы записи 
в префиксную, но не выполняет традиционных функций компи¬ 
лятора. Следовательно, при таком подходе к решению пробле¬ 
мы большая часть объема работ по привязке программы к ма¬ 
шине откладывается до начала выполнения программы. 

Хотя описываемый подход и классифицируется как второе 
из возможных решений в рамках традиционной архитектуры 
фон Неймана, невозможно провести четкую грань, отделяющую 
этот подход от подхода, при котором архитектура ориентиро¬ 
вана на язык высокого уровня. Имеющие место различия носят 
скорее количественный характер: архитектура типа А машин 
языков высокого уровня может рассматриваться как архитек¬ 
тура с высокой степенью ориентации на языки высокого уровня. 

Примерами машин с архитектурой типа А являются систе¬ 
мы реального времени для языка FLUID і[46], бортовая вычис¬ 
лительная система для языка Space Programming Language 
(являющегося производным от языка Jovial) [47], ФОРТРАН - 
машина [48], АЛГОЛЛѴ-машина [49], вычислительная система 
для языка ISPL [50], ЛИСП-микропроцессор [51], другие 
ЛИСП-машины [80, 85] и APL -машина [52]. Кроме этого, для 
ЭВМ модели 25 Системы 360 были разработаны микропрограм¬ 
мы, генерирующие APL -машину [53], а наличие на некоторых 
моделях Системы 370 специальных средств, называемых APL 
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Assist, предоставляет в распоряжение пользователей микропро¬ 
грамму для интерпретации подвергнутых ассемблированию 
APL -программ [54]. Отметим также, что внутренняя организа¬ 
ция процессора Interpreter фирмы Burroughs [55] спроектиро¬ 
вана таким образом, что позволяет создавать на своей основе 
машины языков высокого уровня с архитектурой типа А. 


АРХИТЕКТУРА МАШИН 

ЯЗЫКОВ ВЫСОКОГО УРОВНЯ. ТИП Б 

Архитектура этого типа почти идентична рассмотренной выше 
и тоже представлена ветвью 3 на рис. 3.1. Отличие архитекту¬ 
ры типов А и Б состоит в том, что в машине с архитектурой ти¬ 
па А процесс ассемблирования выполняется программным пу¬ 
тем, а в машине с архитектурой типа Б—аппаратным пли .микро¬ 
программным путем, т. е. в последнем случае машина сначала 
ассемблирует исходную программу, а затем интерпретирует. 
Примерами машин с архитектурой типа Б могут служить APL- 
машины [56—58], ФОРТРАН-машина [59], Эйлер-машина 
[60], БЕИСИК-машина [61], машина, ориентированная на син¬ 
таксис языка [62], АЛГОЛ-машина [63] и, наконец, система 
SYMBOL, рассматриваемая в части III данной книги [64]. 

Отметим, что машинам с архитектурой типа Б присущ тот 
же семантический разрыв между языком и машиной, который 
характеризует машины с архитектурой типа А. Единственным 
достоинством машин с архитектурой типа Б является большая 
скорость процесса ассемблирования, поскольку он реализуется 
аппаратно или микропрограммно; однако для большинства 
практических применений это достоинство не является сущест¬ 
венным. К недостаткам машин с архитектурой типа Б относятся 
более высокая стоимость и меньшие возможности по расшире¬ 
нию (перестройке). Это связано с более высокой стоимостью 
реализации тех или иных функций (а также любых изменений 
этих функций) микропрограммными или аппаратными средст¬ 
вами по сравнению с программным способом. Разработчики вы¬ 
числительных машин часто руководствуются следующими кри¬ 
териями при принятии решения о реализации тех или иных 
функций с помощью микропрограммных или аппаратных 
средств: во-первых, функция должна быть сравнительно прос¬ 
той; во-вторых, должна быть маловероятной потребность ее из¬ 
менения в будущем; в-третьих, должна быть крайне невыгодна 
меньшая скорость выполнения этой функции в случае ее реали¬ 
зации программными средствами. Остается неясным, удовлет¬ 
воряют ли какому-нибудь из этих критериев функции ассемб¬ 
лера. 
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СООТНОШЕНИЯ 

МЕЖДУ ПОКАЗАТЕЛЯМИ СТОИМОСТИ 
АППАРАТНОЙ И ПРОГРАММНОЙ РЕАЛИЗАЦИИ 
ФУНКЦИИ ВЫЧИСЛИТЕЛЬНОЙ СИСТЕМЫ 

Ввиду важности учета экономического фактора сделаем неболь¬ 
шое отступление и рассмотрим соотношения между стоимост¬ 
ными показателями аппаратной и программной реализации тех 
или иных функций (относящихся как к архитектуре машины, 
так и к программному обеспечению последней). 

Если некоторая требуемая функция исключена из списка 
функций, реализуемых аппаратными средствами машины, она 
подлежит выполнению программным путем. Если же она реа¬ 
лизуется аппаратно, это связано с работой определенных ком¬ 
бинационных и последовательных схем и (или) микропрограм- 
мируемых логических схем. Чтобы сопоставить стоимость ука¬ 
занных альтернативных решений, необходимо принять во вни¬ 
мание затраты на разработку и производство соответствующих 
средств. Общепризнанной является высокая стоимость разра¬ 
ботки программного обеспечения. Иногда полагают, что его 
создание не связано с производственными затратами. Однако, 
чтобы убедиться в обратном, достаточно принять во внимание 
затраты на производство запоминающих устройств, необходи¬ 
мых для размещения программного обеспечения. 

По сравнению с реализацией функции программными 
средствами использование микропрограммных средств связано 
с более высокими затратами на разработку и производство. 
Факт высоких затрат на разработку является общепризнанным 
и не требует дальнейших обсуждений. Возрастание производ¬ 
ственных расходов объясняется следующими причинами: во-пер¬ 
вых, традиционное программирование в отличие от микропро¬ 
граммирования характеризуется более высоким уровнем алго¬ 
ритмизации, и вследствие этого требуется меньший объем памя¬ 
ти для результирующей программы; во-вторых, микропрограммы 
обычно хранятся в более быстродействующей, а следовательно, 
и более дорогостоящей запоминающей среде. По сравнению с 
реализацией функции программными и микропрограммными 
средствами использование для этих целей логических схем 
центрального процессора сопряжено с еще более значительны¬ 
ми затратами на их разработку и производство. 

Все предшествующие рассуждения базировались на том, 
что реализация тех или иных функций вычислительной системы 
программными средствами является всегда несколько менее до¬ 
рогостоящей. Однако необходимо принять во внимание еще два 
обстоятельства. Во-первых, изъятие какой-либо функции у ма¬ 
шины может предполагать ее многократную реализацию про- 
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граммными средствами (например, всеми компиляторами). Так, 
если в машине отсутствуют средства вызова подпрограмм, в 
компиляторе каждого языка программирования (и, возможно, 
в ряде прикладных программ) необходимо предусмотреть реа¬ 
лизацию этих средств программным путем. Хотя однократная 
программная реализация этой функции системы может оказать¬ 
ся и дешевле адекватных аппаратных средств, общая стоимость 
всего соответствующего программного обеспечения может быть 
дороже. Во-вторых, необходимо принять во внимание особенно¬ 
сти затрат на производство программных средств. Отсутствую¬ 
щая в машине и реализуемая программно та или иная функ¬ 
ция системы может оказаться многократно дублируемой в па¬ 
мяти машины. Предположим, что в машине не предусмотрена 
возможность адресации к элементам массивов или преобразо¬ 
вания данных из одной формы представления в другую. Тогда 
при каждом «прочтении» компилятором обращения к массиву 
(или запроса на преобразование данных) компилятор должен 
генерировать, например, восемь команд для выполнения требуе¬ 
мой операции. Эти восемь команд появляются в памяти неодно¬ 
кратно (при каждом обращении к массиву или запросе на пре¬ 
образование данных). Последнее обстоятельство увеличивает 
суммарную стоимость производства программных средств. 

Для более детального анализа влияния указанных факторов 
сравним затраты на аппаратную и программную реализации 
некоторой функции в одной и той же системе. Рассмотрим та¬ 
кую функцию системы, реализация которой в машине требует 
и аппаратных и микропрограммных средств. Если Dh и Мь — 
стоимость разработки и производства аппаратных средств реа¬ 
лизации требуемой функции, а V — количество производимых 
вычислительных систем с этой функцией, то стоимость аппарат¬ 
ной реализации этой функции в одной системе равна D h /V+M h . 
(Известно, что Мь меняется с изменением значения V, но для 
простоты это обстоятельство принимать во внимание не будем.) 

Пусть D s — стоимость разработки программных средств реа¬ 
лизации той же функции, M s — стоимость производства этих 
средств (например, стоимость памяти, необходимой для хране¬ 
ния соответствующего фрагмента программы), С — число раз 
генерирования этой функции в форме фрагмента программы, 
R — число раз, которое запрограммированная функция встреча¬ 
ется в памяти в процессе работы системы. Тогда стоимость про¬ 
граммной реализации рассматриваемой функции в одной систе¬ 
ме равна CxDs/V+RxMs. 

В результате имеем уравнение с семью неизвестными. Одна¬ 
ко для большинства вычислительных систем D h »Mh (предель¬ 
ный случай относится к микропроцессорам). Поскольку ранее 
указывалось, что D s <Dh, a M s <Mh, то справедливы следую- 
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щие отношения: Dh>D s >Mh>M s . Согласно рыночным ценам 
1981 г., стоимость «производства» одного оператора программы 
равна —100 долл.; при этом стоимость 16К бит памяти состав¬ 
ляет ~ 1 долл. Полагая, что оператор языка высокого уровня, 
представленный в машинном коде, занимает 20 байт памяти 
ЭВМ стандартной архитектуры, получим D S =10 000XM S . В це¬ 
лях конкретизации дальнейших рассуждений положим также, 
что операнды указанных выше неравенств — члены геометриче¬ 
ской прогрессии, знаменатель которой есть корень квадратный 
из 10 000, т. е. Dh=100XiD s ; D s = 100xMh и т. д. (Отметим, что 
эти соотношения — результат умозрительных заключений, ко¬ 
торые выглядят весьма правдоподобными.) 

Тогда стоимость затрат на аппаратную реализацию равна 
1 000 000xMs/V+100xM s , а на программную реализацию Со¬ 
ставляет 10 000xCxMs/\4-R+Ms. Следовательно, если 
1 000 000/Ѵ+Ю0<;10 000xC/V-f-R, то затраты на аппаратную 
реализацию меньше. Если Ѵ=1 (производится только один 
комплект вычислительной системы), а величина переменной С 
большая, то стоимость аппаратных средств меньше, чем про¬ 
граммных, при С> 100 (программные средства реализации тре¬ 
буемой функции дублируются более 100 раз). Подобная ситуа¬ 
ция возможна, но представляется маловероятной. Для многих 
функций, подлежащих реализации, ситуацией, имеющей боль¬ 
шую вероятность, можно считать такую, при которой Ѵ=10 000, 
а параметры С и R представляют собой значительную величи¬ 
ну; при этом аппаратная реализация дешевле, если C + R>200. 
Весьма вероятна также ситуация, когда при Ѵ= 1000 000 (на¬ 
пример, организовано производство микропроцессора) аппарат¬ 
ная реализация дешевле, если R> 101. Итак, аппаратная реа¬ 
лизация экономически оправданна при следующих обстоятельст¬ 
вах: во-первых, при условии производства большого количества 
экземпляров проектируемой системы; во-вторых, если требуется 
многократное генерирование адекватной программной реализа¬ 
ции; в-третьих, если в памяти машины оказывается большое 
число дубликатов программной реализации требуемой функции. 
Ситуации первого типа обычно возникают при работе с микро¬ 
процессорными наборами, две другие — при использовании 
больших вычислительных систем в мультипрограммном режиме. 

Теперь мы пришли к пониманию того, почему экономически 
неоправданно практическое использование машин языков высо¬ 
кого уровня с архитектурой типа Б. Программная реализация 
процесса ассемблирования (компилирования), вероятнее всего, 
создала бы ситуацию, при которой C = R = 1; в результате усло¬ 
вия для разделения функций между аппаратными и программ¬ 
ными средствами отсутствовали бы; аппаратная реализация 
оказалась бы более дорогой. 
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В заключение следует отметить, что показатель стоимости 
не является единственным критерием в поиске компромисса при 
распределении функций системы между ее аппаратными сред¬ 
ствами и программным обеспечением. Не менее важным является 
такой показатель, как быстродействие. Поскольку быстродей¬ 
ствие аппаратных средств всегда выше, приведенные формулы 
подлежат пересмотру с позиций поиска компромисса между 
стоимостью тех или иных средств и их быстродействием. Оче¬ 
видно, что в ситуациях приблизительно равной стоимости аппа¬ 
ратной и программной реализаций предпочтение будет отдавать¬ 
ся первой. Немаловажными факторами в поиске упомянутого 
выше компромисса являются защита системы от несанкциони¬ 
рованного доступа и функциональная целостность. Если этим 
факторам удаляется значительное внимание, то независимо от 
требований экономии средств и достижения более высокого 
быстродействия предпочтение будет отдано аппаратным сред¬ 
ствам. 


АРХИТЕКТУРА МАШИН 

ЯЗЫКОВ ВЫСОКОГО УРОВНЯ. ТИП В 

Очевидным решением проблемы полного устранения семан¬ 
тического разрыва между языком программирования и маши¬ 
ной и перенесением процесса привязки программы к машине на 
этапе выполнения программ является создание машины, непо¬ 
средственно интерпретирующей язык высокого уровня. На 
рис. 3.1 это решение символически обозначено ветвью 4. Здесь 
стираются различия между понятиями архитектуры машины и 
языка программирования; они становятся идентичными. При¬ 
мерами машин с подобной архитектурой являются APL -машина 
[65], АЛГОЛ-машина [66—68], БЕИСИК-машина [80], 
ФОРТРАН-машина [85], Паскаль-машина [86], ЛИСП-машина 
[71, 80], Jovial -машина [87], машины языков Adam [69], 
IPL [70], LAX [72], машина языка, не имеющего названия 

[74] , и машина со структурой, подстраиваемой под любой язык 

[75] . Машины с архитектурой подобного типа встречаются не 
только в лабораторном (экспериментальном), но и в промыш¬ 
ленном исполнении. Примером машин последнего вида является 
портативная вычислительная машина 5100/5110 фирмы IBM. 
Когда машина, подобная ЭВМ модели 5100, интерпретирует 
программы на языке APL, архитектура ее процессора представ¬ 
ляет собой разновидность архитектуры Системы 370. Этот про¬ 
цессор интерпретирует программно-реализованный интерпре¬ 
татор языка APL, который в свою очередь интерпретирует про¬ 
грамму на языке APL. То же происходит, когда этот процессор 
интерпретирует программы на БЕИСИКе, с той лишь разницей, 
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что в этом случае процессор загружается набором команд, по¬ 
добным набору команд вычислительной системы S/3 фирмы 
IBM, и интерпретирует программно-реализованный интерпрета¬ 
тор языка БЕЙСИК. 

Хотя архитектура типа В и сводит семантический разрыв 
к нулю, ее недостатки представляются столь значительными, 
что архитектуру такого типа вряд ли можно считать перспектив¬ 
ной [84]. Прежде всего не ясно, можно ли вообще в данном 
случае говорить об архитектуре машины. Процесс создания 
архитектуры вычислительной машины предполагает поиск ком¬ 
промисса в распределении ее функций между аппаратными 
средствами и программным обеспечением. Что же касается рас¬ 
сматриваемой архитектуры, то здесь выполнение всех функций 
возлагается на аппаратные средства. Относительно редко ис¬ 
пользуемых функций или таких, скорость реализации которых 
не является важной характеристикой, разработчик принимает 
решения, которые далеки от оптимальных. 

Машины с архитектурой типа В должны быть также менее 
эффективны, чем машины с архитектурой ранее рассмотренных 
типов, прежде всего потому, что вся работа по привязке про¬ 
граммы к машине осуществляется в процессе прогона програм¬ 
мы динамически, а следовательно, методом повторений. При 
каждом выполнении машиной оператора программы должны 
производиться его лексический анализ, синтактический разбор 
этого оператора, преобразование символических имен в адреса 
и т. п. Например, если конкретный оператор IF используется 
1000 раз, то столько же раз осуществляется его синтаксический 
разбор. В то же время в машинах с архитектурой другого типа 
для каждого оператора указанные выше действия производятся 
компилятором или ассемблером только один раз. Исключитель¬ 
ная неэффективность машин с архитектурой типа В объясняет¬ 
ся необходимостью манипуляции символическими именами пе¬ 
ременной длины, оперирования выражениями в инфиксной фор¬ 
ме и сканирования программы в поиске точек перехода (напри¬ 
мер, при обработке операторов IF и обращений к подпрограм¬ 
мам). Высказывались разнообразные предложения [68, 76] по 
устранению этих недостатков, однако сделанные предложения 
являются, по существу, платой за сложность исходных реше¬ 
ний. 

По сравнению с машинами выше рассмотренных архитектур¬ 
ных решений машины с архитектурой типа В по тем же причи¬ 
нам, что и машины с архитектурой типа Б, отличаются более 
высокой стоимостью и меньшей способностью к перестройке и 
расширению своих функциональных возможностей. 

Еще одним недостатком машин с архитектурой типа В 
является отсутствие процедуры (типа компилирования или ас- 
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семблирования), осуществляющей анализ программы до ее вы¬ 
полнения. Очень часто забывают об одном очень важном до¬ 
стоинстве компилятора или ассемблера — способности обнару¬ 
живать в программе синтаксические ошибки. В машине данно¬ 
го типа ошибки не выявляются вплоть до этапа выполнения 
программы (например, синтаксическая ошибка в конкретном 
операторе может оставаться незамеченной даже по истечении 
30 мин выполнения программы). Конечно, можно создать пред- 
процессор для анализа синтаксических ошибок, однако это по¬ 
влекло бы дополнительные расходы; пришлось бы двукратно 
производить синтаксический анализ программы: предпроцессо¬ 
ра и непосредственно в ходе выполнения машиной программы. 
Конечно, в таком случае предпроцессор мог бы преобразовы¬ 
вать исходную программу в форму, более удобную для после¬ 
дующего выполнения. Однако в результате машина с архитек¬ 
турой типа В была бы превращена в машину с архитектурой 
типа А или Б. 

Заметим, наконец, что проекты построения машин с архитек¬ 
турой типа В часто упускают из виду реализацию таких функ¬ 
ций (являющихся скорее функциями системы, а не языка про¬ 
граммирования), как ввод-вывод, управление вычислительным 
процессом и управление ресурсами памяти. 

В заключение укажем, что в дальнейшем в данной книге 
архитектура типа В рассматриваться не будет, поскольку при 
формулировании принципов ее построения не учитывались тот 
факт, что некоторые функции системы лучше реализовать про¬ 
граммными средствами, а также то обстоятельство, что наилуч¬ 
шим решением является преобразование исходной программы 
на этапе, предшествующем ее выполнению. 

АРХИТЕКТУРА МАШИНЫ 
И КОМПИЛЯТОРЫ 

Простота компилирования программ — один из доводов в поль¬ 
зу построения машин с архитектурой, ориентированной на язык 
программирования. Существует мнение, что «главным достоин¬ 
ством той или иной машины с архитектурой, ориентированной 
на язык Паскаль, является упрощение процесса разработки 
компилятора», и, кроме того, «стеки имеют преимущество перед 
регистрами в том, что упрощают формирование кодов для раз¬ 
работчика компилятора». К утверждениям подобного рода сле¬ 
дует относиться критически, поскольку они часто носят дезин¬ 
формирующий характер. 

В общем случае разработчику вычислительной системы не 
следует обращать чрезмерное внимание на те последствия, ко¬ 
торые оказывают на компилятор формулировка принципов по- 
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строения и принятие решений об организации архитектуры си¬ 
стемы. В настоящее время типичные вычислительные системы 
(микропроцессорные, ЭВМ индивидуального пользования, не¬ 
большие системы для делопроизводства, малые и сверхбольшие 
ЭВМ) могут быть оснащены одним или несколькими компиля¬ 
торами, операционной системой или управляющей программой 
и другими программными средствами, поставляемыми произ¬ 
водителями машин (библиотеками подпрограмм, программами- 
утилитами, лицензионными прикладными программами). Повы¬ 
шенное внимание к проблеме снижения стоимости разработки 
компилятора окажется необоснованным, если принять во вни¬ 
мание весь комплекс усилий, затрачиваемых на разработку 
исходного объема аппаратных средств и программного обеспе¬ 
чения проектируемой системы, а также учесть все те програм¬ 
мы (возможное количество которых измеряется тысячами), ко¬ 
торые предназначены для системы и подлежат разработке в 
последующий период. Больший ущерб может нанести прене¬ 
брежение каким-либо более важным фактором. 

Как уже неоднократно упоминалось, перед разработчиком 
архитектуры вычислительной системы стоит задача компро¬ 
миссного распределения функций системы между аппаратными 
средствами и программным обеспечением, оптимизация этого 
распределения с учетом их стоимости, анализа функционирова¬ 
ния системы на микро- и макроуровнях, проблем модификации 
системы, ее надежности и т. д. При анализе функционирования 
системы на макроуровне особое внимание уделяется влиянию 
выбора варианта построения архитектуры на стоимость соот¬ 
ветствующего программного обеспечения. Как известно, компи¬ 
лятор — это только часть программного обеспечения, которая 
создается лишь один раз, а потребность в написании приклад¬ 
ных программ может возникать ежедневно. Принимая во вни¬ 
мание это обстоятельство, а также то, что специализированные 
программы, как правило, разрабатываются соответствующими 
специалистами, трудно найти достаточно убедительные доводы 
в пользу выбора варианта построения архитектуры системы, 
руководствуясь прежде всего желанием минимизировать затра¬ 
ты на разработку компилятора. При анализе функционирования 
системы на микроуровне также не представляется обоснован¬ 
ным стремление к увеличению скорости процесса генерирования 
компилятором машинных кодов. В конечном счете вычислитель¬ 
ная система создается не как машина для компилирования про¬ 
грамм, а как средство эффективного выполнения программ, 
прошедших этап компилирования (что, возможно, имело место 
несколько месяцев или лет тому назад). 

Проблемы, связанные с процессом компилирования, не име¬ 
ют универсальных решений, как, впрочем, и большинство дру- 
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гих проблем архитектуры вычислительных машин. Однако су¬ 
ществуют по крайней мере две ситуации, в которых от разра¬ 
ботчика архитектуры ЭВМ требуется особое внимание к про¬ 
цессу компилирования: 1) система вынуждена затрачивать не¬ 
обычно много времени на компилирование (например, система 
проектирования микропроцессоров); 2) архитектура системы 
препятствует настройке компилятора на оптимизацию порож¬ 
даемых им машинных кодов. В первом случае, встречающемся 
довольно редко, у разработчика архитектуры ЭВМ имеются до¬ 
статочные основания быть озабоченным проблемой скорости 
компилирования, хотя ее решение вовсе не обязательно связано 
с увеличением затрат на разработку компилятора. Во втором 
случае влияние организации вычислительной системы в целом 
на успех решения проблемы очевидно. Однако это обстоятель¬ 
ство может оказаться не столь значительным, поскольку боль¬ 
шая часть работы по оптимизации может быть выполнена без 
учета специфики конкретного архитектурного решения. 

В заключение отметим, что нет ничего принципиально оши¬ 
бочного в стремлении добиться от разработчика архитектуры 
ЭВМ определенных решений, упрощающих компилятор или об¬ 
легчающих труд по его написанию; все зависит от того, чему 
именно уделяется наибольшее внимание. Если при решении ос¬ 
новных проблем архитектуры машины попутно удается упрос¬ 
тить компилятор и увеличить скорость его работы, это можно 
только приветствовать. Однако к этому следует относиться 
как к полезному побочному эффекту, но не цели проектирова¬ 
ния архитектуры. 

УПРАЖНЕНИЯ 

3.1. Одной из опасностей попыток сокращения семантического разрыва 
между машиной и данным языком программирования является возможное 
увеличение семантического разрыва между этой машиной и другим языком 
программирования. Сформулируйте несколько подходов, используя которые 
можно решить эту проблему. 

3.2. Учитывая сравнительную всеобъемлемость архитектуры машин язы¬ 
ков высокого уровня и архитектуры, ориентированной на подобные языки, 
укажите, какие языки «выпали из поля зрения» этих архитектурных реше¬ 
ний? 
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ГЛАВА 4 

НАБОР СРЕДСТВ ДЛЯ СОВЕРШЕНСТВОВАНИЯ 
АРХИТЕКТУРЫ ВЫЧИСЛИТЕЛЬНОЙ СИСТЕМЫ 

На основе анализа проблем машин традиционной архитектуры 
может быть разработан набор решений по сокращению семан¬ 
тических разрывов различного вида, рассмотренных в гл. 2. 
Эти решения не сводятся к таким упрощенным рекомендациям, 
как увеличение «мощности» системы машинных команд (напри¬ 
мер, за счет добавления в традиционную архитектуру специаль¬ 
ного оператора DO, управляющего выполнением цикла ко¬ 
манд). Скорее они предполагают более радикальные изменения, 
например, введение новых принципов организации памяти ма¬ 
шины, предопределяя тем самым отход от классической модели 
машины фон Неймана. Подобные радикальные изменения при¬ 
водят и к увеличению «мощности» (функциональных возможно¬ 
стей) системы машинных команд, но это — лишь вторичный эф¬ 
фект изменения структуры памяти. 

В этой главе указанные изменения рассматриваются с общих 
позиций, без детализации и конкретного описания или практи¬ 
ческой реализации. Но поскольку архитектура системы 
SWARD (детально обсуждаемая в части V) базируется на 
большинстве из рассматриваемых здесь принципов, ссылки на 
нее и примеры реализованных в ней решений составляют осно¬ 
ву иллюстративного материала данной главы. Для получения 
более полного представления об основных положениях этой 
главы читателю следует обратиться к архитектуре вычислитель¬ 
ных систем, рассматриваемых в последующих частях книги. 

САМООПРЕДЕЛЯЕМЫЕ ДАННЫЕ 

Значительным шагом на пути сокращения семантического раз¬ 
рыва между языком программирования и архитектурой машины 
и существенным отходом от классической модели машины фон 
Неймана является хранение информации в фррме самоопреде- 
ляемых данных; применительно к памяти этот принцип получил 
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наименование принципа теговой памяти. Традиционная архитек¬ 
тура фон Неймана базируется на том, что параметры содержи¬ 
мого памяти носят субъективный характер, существуя лишь в 
представлении пользователя памятью, т. е. программы. Маши¬ 
на получает информацию о типе хранимых в памяти данных 
только из потока обрабатывающих команд. Следовательно, 
предполагается наличие команд, определяющих атрибуты опе¬ 
рандов. Так, в Системе 370 проводится четкое различие между 
командами, выполняющими сложение 32-битовых двоичных 


I Тег I .Содержимое слова памяти 


Рис. 4.1. Самоопределяемое слово памяти. 


целых чисел, 16-битовых двоичных целых чисел, 32-битовых чи¬ 
сел с плавающей точкой, 64-битовых чисел с плавающей точ¬ 
кой, 128-битовых чисел с плавающей точкой, одноразрядных де¬ 
сятичных чисел, трехразрядных десятичных чисел и т. д. Аль¬ 
тернативным является такой подход, при котором к ячейке памя¬ 
ти, предназначенной для хранения той или иной информации, 
добавляется набор битов, описывающих атрибуты (тип дан¬ 
ных) содержимого ячейки (рис. 4.1). Термин «ячейка» исполь¬ 
зуется вместо термина «слово», поскольку последнее часто сим¬ 
волизирует область памяти определенного размера; однако при¬ 
держиваться этого ограничения не обязательно. 

В простейшем случае (минимальные требования) поле само¬ 
определения данных, или так называемый тег, содержит инфор¬ 
мацию о типе данных рассматриваемой ячейки (т. е. биты тега 
указывают тип данных, находящихся в ячейке: двоичное целое 
число, десятичное целое число, число с плавающей точкой, стро¬ 
ка символов, адрес и т. п.). Благодаря этому при работе с ячей¬ 
ками можно пользоваться командами, инвариантными к типу 
обрабатываемых данных. Вместо группы команд ADD (СЛО¬ 
ЖЕНИЕ) машине достаточно иметь одну команду: тип подле¬ 
жащего выполнению сложения (арифметика целых чисел, 
арифметика чисел с плавающей точкой и т. п.) машина выявля¬ 
ет путем анализа содержимого тегов операндов каждой коман¬ 
ды. Наличие полей тегов «скрыто» от программ, написанных на 
языках высокого уровня. Теги устанавливаются компиляторами 
или эквивалентными им программными средствами и исполь¬ 
зуются машиной для определения семантики (назначения) каж¬ 
дой подлежащей выполнению операции, контроля адекватности 
обрабатываемых данных (например, архитектура машины мо¬ 
жет предусматривать отказ выполнения сложения адреса с 
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числом в форме с плавающей точкой) и автоматического пре¬ 
образования данных (возможен такой вариант построения ар¬ 
хитектуры машины, при котором сложение целочисленного опе¬ 
ранда с операндом в форме с плавающей точкой допустимо и 
предполагает предварительное соответствующее преобразование 
данных). 

Развивая принцип использования ячеек памяти с тегом, 
можно описывать не только тип хранимых в ячейках данных, но 
и другие их характеристики (в работе [1] предлагается до 
32 типов подобных характеристик). Например, при работе с 
данными переменной длины в теге можно выделить поле для 
указания длины операнда. Это, в частности, позволило бы из¬ 
бавиться от повторения указателя длины данных в каждой 
команде, обращающейся к соответствующему слову данных. 
Так, например, в Системе 370 имеется 15 различных команд 
ADD. Формат одной из них — ADD DECIMAL —предусматри¬ 
вает наличие двух 4-битовых полей для указания длины обоих 
операндов команды. С учетом подобных отличий можно ска¬ 
зать, что в Системе 370 имеется 270 различных команд ADD: 
14 основных и 256 модификаций команды ADD DECIMAL. 
В машине с теговой организацией памяти — при условии, что в 
каждом теге содержится описание типа и длины операнда, — 
вполне достаточным могло бы оказаться использование только 
одной команды ADD. 

Сам факт принятия решения об использовании теговой па¬ 
мяти и команд, инвариантных к типу и длине обрабатываемых 
данных, наводит на мысль о других возможных применениях 
тега. Добавив к нему 1-битовое поле, можно указывать, напри¬ 
мер, определено ли текущее значение переменной, использую¬ 
щей данную ячейку памяти. А это предоставляет для машины 
возможность легко выявлять попытки использования неопреде¬ 
ленных данных. В микропроцессоре обработки числовых дан¬ 
ных 8087 фирмы Intel для этой и других целей используется 
2-битовый тег. Тег можно расширить, добавив поле для так на¬ 
зываемых битов захвата О. Например, подобный бит может 
быть определен таким образом, что при обращении программы 
к ячейке памяти с подобным тегом возникает прерывание, со¬ 
провождаемое выполнением определенных процедур отладки. 

На рис. 4.2 приведены ячейки памяти четырех типов, ис¬ 
пользование которых предусмотрено архитектурой системы 
SWARD (см. часть V). Здесь размер и формат тегов зависят 
от представляемой ими информации, однако во всех случаях 
первые чет ыре бита определяют тип ячейки (точнее, тип дан- 

!) Захват — незапрограммированное прерывание программы при возник¬ 
новении непредусмотренной ситуации с условным переходом к определенной 
процедуре. — Прим. ред. 
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ных, для которых ячейка предназначена). На данном рисунке 
граница между концом тега и началом информационной части 
ячейки (содержимое ячейки) обозначена стрелкой. Для указан¬ 
ной архитектуры характерна инвариантность (неизменяемость) 
содержимого тега ячейки в процессе выполнения программы. 
Исключением являются только ячейки с динамическим опреде¬ 
лением тегов. Это свидетельствует об ориентации данной архи¬ 
тектуры на языки программирования с детально разработанны- 

I _ 

Целое число I 1111 I Значение числа \ 


4 24- 



Рис. 4.2. Типы ячеек памяти в архитектуре системы SWARD. (Поле 
«значение числа» является частным случаем поля «значение символов».) 


ми средствами задания типов переменных, т. е. языки, каждая 
переменная которых имеет строго определенные атрибуты. При 
этом ячейки не существуют как самостоятельные, независимые 
элементы памяти; напротив, они принадлежат информационным 
объектам того или иного типа. Подобный объект может со¬ 
стоять из одной ячейки, набора ячеек, совокупности ячеек и 
машинных команд или структурно более сложных компонентов. 

Вместо того чтобы использовать тег для описания неопреде¬ 
ленного значения, последнее описывается как одно из возмож¬ 
ных значений содержимого ячеек всех типов. Рассмотрим,, на¬ 
пример, ячейку для представления числа в форме с фиксиро¬ 
ванной точкой, а именно десятичного числа в виде целой и 
дробной частей. Содержимое тега определяет тип ячейки (хра¬ 
нилище числа с фиксированной точкой), количество цифр, за¬ 
писываемых в ячейку в коде BCD, и позицию подразумеваемой 
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десятичной точки. Положим, что ячейка предназначена для 
хранения чисел, имеющих следующий формат: ХХХХ.ХХ. Если 
содержимому ячейки в данный момент присваивается значение 
5.7, то в памяти оно представляется как Е620000570 (шестнад¬ 
цатеричная форма записи). Если же содержимое этой ячейки 
не было определено, то имело бы следующий вид: E62FXXXXXX, 
где X — любой символ. 

достоинства теговой памяти 

Расширенные возможности обнаружения ошибок. Совместное 
хранение данных и их атрибутов позволяет машине обнаружи¬ 
вать в программе ошибки нескольких типов. Например, в ар¬ 
хитектуре может быть предусмотрена индикация как ошибоч¬ 
ной ситуации, при которой операнды команды оказываются 
бессмысленными (например, выясняется, что операндом коман¬ 
ды умножения является строка символов), несовместимым» 
(при попытке записи числа с плавающей точкой в качестве ад¬ 
реса) или неопределенными по значению (значение исходного 
операнда неизвестно). Такой механизм называют защитой типа 
данных, поскольку он предотвращает попытки выполнения опе¬ 
раций над данными, тип которых задан некорректно. 

Автоматическое преобразование данных. Теговая организа¬ 
ция памяти позволяет машине выполнять автоматическое пре¬ 
образование данных — операндов команды при условии, что 
они совместимы, но отличаются длиной или формой представ¬ 
ления. Так, в архитектуре машины может быть предусмотрено 
сложение целых чисел в форме с плавающей точкой; машина 
автоматически преобразует данные, являющиеся операндами 
команды ADD. В качестве другого примера можно рассмотреть 
ситуацию, когда операндами команды являются два числа с 
фиксированной точкой, находящейся в разных позициях: в про¬ 
цессе выполнения команды машина осуществляет необходимое- 
выравнивание позиций указанных десятичных точек. 

Повышенная эффективность выполнения программы. Благо¬ 
даря теговой организации памяти достигается высокая скорость 
выполнения команд. Отчасти это является следствием перечис¬ 
ленных выше достоинств теговой памяти. В машине, память ко¬ 
торой не использует теги, необходимые преобразования данных 
выполняют кодовые последовательности, генерируемые компи¬ 
лятором. Скорость выполнения преобразований данных в маши¬ 
не с теговой памятью выше хотя бы потому, что машине, не- 
располагающей подобной памятью, необходимо извлекать из 
памяти и декодировать команды преобразования данных. 

Использование теговой памяти позволяет разработчику ЭВМ 
создавать более эффективные алгоритмы. Рассмотрим задачу 
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увеличения на 1 значения 15-разрядного числа, представленного 
в коде BCD. Большинство машин, использующих подобное 
представление чисел переменной длины, выполняет такие ариф¬ 
метические операции путем последовательных элементарных 
приращений, например побайтно в единицу времени. При реше¬ 
нии этой задачи вручную — с помощью карандаша и бумаги — 
естественно прекратить операции при наличии 0 в качестве циф¬ 
ры переноса. Это можно сформулировать следующим образом: 
прибавить 1 к цифре младшего разряда; если переноса нет, 
операции прекратить; в противном случае добавить единицу 
переноса к цифре следующего разряда и т. д. Поскольку Систе¬ 
ма 370 не использует теговую организацию памяти, результат 
арифметической операции приходится представлять в соответ¬ 
ствующей форме, т. е. в коде BCD. Поскольку машина не мо¬ 
жет гарантировать, что десятичный операнд, расположенный в 
памяти, содержит цифры в коде BCD (в той или иной области 
памяти данной программы байты могут содержать некоторые 
произвольные данные), операция должна быть выполнена над 
всеми частями операнда, т. е. над всеми 15 цифрами. Иначе 
обстоит дело при использовании машины с теговой памятью: 
согласно принципам, положенным в основу подобной архитек¬ 
туры, ячейка, предназначенная для десятичных чисел, не мо¬ 
жет содержать ничего, кроме цифр в коде BCD. Следователь¬ 
но, защита типа представляемых данных является преимуще¬ 
ством машин с теговой организацией памяти. 

Принцип теговой организации памяти позволяет задержать 
начало процесса «привязки» команды к данным до момента ее 
выполнения, что, как предполагается, повышает скорость вы¬ 
полнения программы на языке высокого уровня (если правила 
использования такого языка требуют указанной задержки). На¬ 
пример, при определенных обстоятельствах для программы на 
языке ПЛ/1 необходимо обеспечить привязку атрибутов данных 
на этапе выполнения. Это демонстрирует следующий фрагмент 
программы: 

ABC: PROCEDURE (С); 

DECLARE С CHARACTER (• ); 

DECLARE D CHARACTER (8) INITIAL (’ZYXWVUTS’); 

IF C = D THEN... 

Здесь указано, что длина параметра С задается динамиче¬ 
ски, т. е. принимает размер соответствующего фактического 
параметра. Поэтому для данного оператора IF компилятор не 
может сформировать единственную команду сравнения, как это¬ 
го следовало ожидать в случае, если бы архитектура машины 
была подобна архитектуре Системы 370. Вместо этого необхо- 
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димо создание специальных условий, обеспечиваемых про¬ 
граммными средствами архитектуры с теговой организацией па¬ 
мяти. Благодаря этому размер фактического параметра переда¬ 
ется в процессе вызова процедуры, и тем самым обеспечивается 
динамическое использование его значения для сравнения пере¬ 
менных С и D. На пути выполнения этой операции находится 
еще одно препятствие: перед сравнением длина переменных С 
и D должна быть выравнена. Для этого можно произвести усе¬ 
чение или дополнение D пробелами до размера С. Чтобы осу¬ 
ществить это, компилятор традиционной машины должен соз¬ 
дать некий программный эквивалент подобных возможностей 
машины с теговой памятью. В случае использования оптимизи¬ 
рующего компилятора языка ПЛ/1, разработанного фирмой 
IBM, генерируется 49 команд (вместо одной команды машины 
с теговой памятью). Это же справедливо и в отношении других 
языков программирования, таких, как Ада. 

Меньшее разнообразие типов команд. В отличие от машины 
с традиционной архитектурой в машине с теговой памятью 
обычно используются команды, инвариантные к типу обрабаты¬ 
ваемых данных, вследствие чего существенно сокращается об¬ 
щий набор команд, их структура приобретает более регулярный 
характер, отсутствуют многие аномалии, столь типичные для 
больших наборов команд. В результате архитектура с теговой 
организацией памяти становится более «понятной» компилято¬ 
рам и программистам. 

Архитектуре многих машин присуща корреляция между раз¬ 
мером набора команд и числом аномалий в архитектуре. На¬ 
пример, в Системе 370 имеются двоичные данные двух типов: 
длиной 16 и 32 бит. Набор команд обработки 32-битовых дан¬ 
ных включает команды ADD (СЛОЖЕНИЕ), SUBTRACT (ВЫ¬ 
ЧИТАНИЕ), MULTIPLY (УМНОЖЕНИЕ) и DIVIDE (ДЕЛЕ¬ 
НИЕ), в то время как в наборе команд обработки 16-битовых 
данных команда деления отсутствует. Имеется команда HALVE 
(ДЕЛЕНИЕ ПОПОЛАМ) — деление числа с плавающей точ¬ 
кой на 2. Существование этой команды может вызвать удивле¬ 
ние, поскольку имеется соответствующая команда DIVIDE. 
При этом отсутствует команда DIVIDE BY 2 (ДЕЛЕНИЕ НА 
2) для двоичных или десятичных целых чисел (в противополож¬ 
ность распространенному мнению операция арифметического 
сдвига не эквивалентна делению на 2 [3]). 

Более простой компилятор. По сравнению с традиционными 
машинами для машины с теговой памятью используется более 
простой и требующий меньшего времени выполнения компиля¬ 
тор. (В гл. 3 этот факт отмечен как положительный побочный 
эффект, а не основная цель теговой организации памяти.) Про¬ 
цесс генерирования машинных кодов компилятором традицион- 



ной машины довольно сложный, поскольку необходим семанти¬ 
ческий анализ программы для определения того, какие именно 
команды подлежат генерированию. Например, встретив знак 
операции +, компилятор вынужден анализировать выражения, 
расположенные по обе стороны от знака, чтобы принять реше¬ 
ние о типе команды сложения, подлежащей генерированию. 
В машине с теговой памятью компилятор просто генерирует 
команду сложения (принадлежащую набору команд, инвари¬ 
антных к типу обрабатываемых данных). И если компилятор 
традиционной машины вынужден осуществлять выбор букваль¬ 
но из сотен возможных кодовых последовательностей для опе¬ 
ратора IF А=В THEN..., компилятор машины с теговой па¬ 
мятью всегда пользуется одной и той же машинной командой. 
Простота генерирования машинных кодов в последнем случае 
объясняется также и тем, что не компилятор, а машина на эта¬ 
пе выполнения осуществляет контроль корректности програм¬ 
мы и автоматическое преобразование данных. 

Более совершенные средства отладки. Теговая организация 
памяти вычислительной машины упрощает процесс разработки 
средств отладки программ. По крайней мере наиболее простые 
общеиспользуемые средства, базирующиеся на выдаче дампа 
памяти, оказываются более эффективными. Это связано с тем, 
что при теговой организации памяти дамп значительно инфор¬ 
мативнее для пользователя (благодаря большей наглядности 
выводимого на печать содержимого областей памяти) по срав¬ 
нению с традиционным дампом в виде длинных последователь¬ 
ностей двоичных, восьмеричных и шестнадцатеричных цифр. 
Возможность включения в теги битов захвата делает более ве¬ 
роятной практическую реализацию сравнительно сложных 
средств отладки. Кроме того, любое архитектурное решение, 
обеспечивающее сближение интерфейса машины с языком про¬ 
граммирования, способствует разработке средств отладки, ори¬ 
ентированных на эти языки. 

Независимость программных средств от обрабатываемых 
данных. Поскольку применение тегов позволяет отложить мо¬ 
мент привязки алгоритма работы программы к атрибутам дан¬ 
ных на наиболее поздний этап обработки задания (программы 
и данных), появляется возможность использования инвариант¬ 
ных к типу данных команд для написания программы и реали¬ 
зации принципа независимости программных средств от дан¬ 
ных в структуре базы данных. Указанный принцип независимо¬ 
сти позволяет прикладным программам обрабатывать отдель¬ 
ную запись базы данных (логическую запись) без учета ее фи¬ 
зического представления (физической записи). В простейшем 
случае, например, прикладная программа может «полагать», 
что содержимое некоторого поля — десятичное число, хотя в 
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реальной базе данных в этом поле может находиться двоичный 
эквивалент этого числа. 

Практическая реализация рассматриваемого принципа в су¬ 
ществующих вычислительных системах затруднена тем, что их 
машинные команды содержат информацию о типе и длине сво¬ 
их операндов, а поэтому при внесении изменений в определение 
базы данных требуется повторное компилирование ее программ¬ 
ных средств. Что же касается машин с теговой организацией 
памяти, то благодаря использованию команд, инвариантных к 
типу данных, и при условии распространения теговой организа¬ 
ции на внешнюю память, практическое осуществление принципа 
независимости программных средств от данных становится ре¬ 
альностью. 

Уменьшение необходимого объема памяти. Речь идет о до¬ 
стоинстве машин с теговой организацией памяти, которое по 
интуитивным, но ошибочным соображениям многим кажется 
спорным и даже противоречивым. В таких машинах для разме¬ 
щения программы и данных требуется меньший объем памяти, 
чем в машинах с традиционной, «нетеговой» организацией па¬ 
мяти. Объяснению этого явления посвящен следующий раздел. 

ПАМЯТЬ. НЕОБХОДИМАЯ 
для РАЗМЕЩЕНИЯ ТЕГОВ 

Получившая распространение критика принципа теговой орга¬ 
низации памяти обычно основана на интуитивном предположе¬ 
нии, что стоимость системы, использующей теги, возрастает 
вследствие увеличения требуемого объема памяти. Утверждают, 
например, что добавление 4-битового тега к 32-битовым словам 
машины увеличивает стоимость ее памяти на 12,5%. Однако в 
данном случае интуиция явно подводит: машине с теговой па¬ 
мятью требуется меньшее количество битов памяти, чем маши¬ 
не с традиционной архитектурой. 

Прежде всего следует отметить, что традиционным машинам 
присуща значительная избыточность хранимой в памяти инфор¬ 
мации об атрибутах данных. Так, если число с плавающей точ¬ 
кой адресуется многими командами, имеет место избыточность 
в повторной идентификации каждой такой командой данного 
числа как операнда в форме с плавающей точкой (в поле кода 
операции команды имеются биты, позволяющие отличить опе¬ 
рацию арифметики чисел с плавающей точкой от арифметики 
чисел других типов). Поскольку к переменным адресуются, как 
правило, несколько команд, представляется рациональным для 
сведения расхода памяти к минимальному устранять избыточ¬ 
ность в повторяемых командах за счет хранения информации о 
типе операнда команды вместе с самим значением операнда 
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(хранение информации в статическом виде). 

В качестве простого примера рассмотрим машину X со 150 
типами различных команд, код операции каждой из которых 
занимает поле длиной 8 бит. Альтернативой этой машины бу¬ 
дем считать машину Y с теговой памятью, каждая ячейка ко¬ 
торой содержит 3-битовый тег. Команды машины Y являются 
инвариантными к типу обрабатываемых данных. Это позволя¬ 
ет предположить, что для решения тех же задач, которые сто¬ 
ят перед машиной X, машине Y окажется достаточно только 
50 типов команд, код операции каждой из которых может быть 
описан б бит. 

Для сравнения объема памяти, расходуемой той и другой 
машинами, следует определить (в битах) количество кодов опе¬ 
рации и тегов, необходимых некоторой программе, — назовем 
эту сумму В. При этом предполагается, что все остальные по¬ 
требности в памяти являются неизменными для обеих машин. 
Если 1 есть количество машинных команд программы, то для 
машины X справедливо равенство В = 8-1. Для машины Y име¬ 
ет место соотношение В=6-І+3-Р, где Р — число операндов в 
программе. В предположении, что каждая команда обеих ма¬ 
шин манипулирует двумя операндами и к каждому операнду в 
программе производится в среднем R обращений, для машины 
Y получим равенство B = 6-I+6-I/R. Отношение величины В 
машины Y к величине В машины X равно 0,75- (1 + 1/R). Если 
значение этого отношения меньше 1, то машина с теговой па¬ 
мятью расходует меньше памяти. 

Для количественной оценки полученного отношения необхо¬ 
димо знать, чему равно значение параметра R, т. е. значение 
среднего числа обращений к операнду одной команды. Естест¬ 
венно ожидать, что его величина больше 1. Критическим явля¬ 
ется значение R, равное 3; при этом условии для обеих машин 
требуется одинаковый объем памяти. Параметр R не относит¬ 
ся к числу часто измеряемых показателей работы программы. 
Согласно результатам экспериментов с одним набором про¬ 
грамм [4], его величина равна 10,4. При оценке среднего чис¬ 
ла обращений к операнду в программах на языке КОБОЛ эта 
величина составила 3,5 [5]. Если воспользоваться значением 
10,4 как типичной величиной для программы в машинных ко¬ 
дах, то для размещения кодов операции команд и тегов данных 
в машине с теговой организацией памяти потребуется 82% объ¬ 
ема памяти, необходимой для выполнения тех же программ в. 
машине с традиционной архитектурой. Если же положить R 
равным 3,5, то указанная величина станет равной 96%. 

Итак, для машины с теговой организацией памяти требует¬ 
ся меньший объем памяти благодаря устранению избыточности 
информации в кодах операции команд. Этот противоречащий! 
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интуиции феномен подтверждает одно из положений, сформули¬ 
рованных в гл. 1: только глубокое понимание языков програм¬ 
мирования и специфических характеристик программ позволя¬ 
ет разработчику архитектуры вычислительной системы прини¬ 
мать рациональные решения. 

Таблица 4.1. Ресурсы машины, расходуемые 
на автоматическое преобразование данных 
и проверку результата на переполнение 


Оператор 

Машинные 

команды 

Размер, 

байт 

полнения, 

Без контроля на пе¬ 
реполнение 

D=D+A; 

1 

6 

13,1 

407,6 

D=D+I; 

13 

64 

С контролем на пере¬ 
полнение 

D=D+A; 

7 

38 

57,7 

D=D+I; 

19 

92 

448,1 


Использование тегового принципа организации памяти по¬ 
зволяет уменьшить ее объем и за счет устранения избыточ¬ 
ности другого типа: команд, повторно генерируемых компиля¬ 
тором для выполнения функций контроля и преобразования 
данных на этапе выполнения программы. Положим, что в про¬ 
грамме на языке ПЛ/1 переменная I объявлена как FIXED 
BINARY (31), а переменные А и D — как FIXED DECIMAL (4,2). 
В Системе 370 при использовании оптимизирующего ком¬ 
пилятора языка ПЛ/1 машинный код, генерируемый для опера¬ 
тора D = D+A, занимает 6 байт памяти, а для размещения кода 
для оператора D = D + I требуется 64 байт (табл. 4.1), т. е. про¬ 
исходит увеличение на 967%. Это объясняется тем, что во вто¬ 
ром случае компилятор генерирует код для преобразования дан¬ 
ных. Если задать необязательный параметр проверки операции 
записи в область D на переполнение, то для оператора D = D + I 
генерируется 92 байт объектного кода. Согласно табл. 4.1, уве¬ 
личение времени выполнения команд еще значительнее: выпол¬ 
нение оператора D = D + I, содержащего операнды разных ти_- 
пов, составляет 3011% времени выполнения оператора D = D+A 
(измерения проведены на ЭВМ модели 145 Системы 370). 

Указанные операции контроля и преобразования данных 
представляются обычно в виде машинных кодов, встроенных в 
том месте объектного кода программы, где они необходимы. 
Однако такое решение не является обязательным. Коды этих 
операций можно формировать в виде подпрограмм, вызывае¬ 
мых по мере необходимости. Единственная причина, по которой 
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так обычно не поступают, заключается в чрезвычайной неэф¬ 
фективности реализации такого варианта. Теговая организация! 
памяти позволяет устранить упомянутую выше избыточность, 
возложив выполнение указанных функций на машину. Конеч¬ 
но, эти функции необходимо реализовать в какой-то определен¬ 
ной форме, например в виде информации, занимающей некото¬ 
рый объем управляющей памяти машины с микропрограммным 
управлением. Однако в машине с теговой памятью эти функции 
физически реализуются только один раз (в заданной области 
управляющей памяти), вместо того чтобы дублироваться сотни 
или тысячи раз в объектном коде программы, размещаемой в 
основной памяти машины. 

Ранее при рассмотрении влияния тегов на скорость выпол¬ 
нения программы отмечалось, что при использовании некото¬ 
рых языков программирования требуется динамическая при¬ 
вязка (назначение) атрибутов данных командам. При использо¬ 
вании памяти без тегов это условие реализуется с помощью ма¬ 
шинных кодов, генерируемых компилятором, что, безусловно, 
влечет за собой дополнительный расход памяти. В рассмотрен¬ 
ном выше примере (для переменных С и D) решение подобной 
задачи компилятором сопровождается генерированием 156 байт 
машинного кода. Если же динамической привязки атрибутов 
данных командам не требуется, например, если С определена 
как переменная фиксированной длины, то оказывается доста¬ 
точно 6 байт подобного кода. 

Приведем последний довод в пользу утверждения, состояще¬ 
го в том, что тегам требуется не так много памяти, как кажет¬ 
ся на первый взгляд. Тег не является физически неотъемлемой 
частью каждого элемента данных теговой памяти. Например, 
нет необходимости хранить тег для каждого элемента массива. 
Поскольку, согласно определению массива, его элементы имеют 
идентичные атрибуты, можно ограничиться одним тегом для 
всего массива. По той же причине не требуется наличия тега 
для каждого элемента строки символов; достаточно иметь один 
тег, определяющий атрибуты всех элементов. Более подробно 
этот вопрос анализируется в следующем разделе. 

НЕДОСТАТКИ ТЕГОВОЙ ПАМЯТИ 

Как и следовало ожидать, теговой памяти присущи недостатки. 
Одним из них является сам факт строгого определения типа 
данных, что иногда трудно совместимо с возможностями су¬ 
ществующих языков программирования, не обладающих адек¬ 
ватной строгостью и точностью определения типов переменных 
(см. упр. 4.1). Другим недостатком теговой памяти являются 
ограничения, накладываемые ею на скорость выполнения опе¬ 
раций. И это наряду с отмеченными выше достоинствами те- 
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говой памяти при сравнении ее быстродействия с быстродей¬ 
ствием традиционной памяти машины. 

Указанные ограничения вызваны тем, что при использовании 
теговой памяти процесс привязки атрибутов данных командам 
откладывается на этап выполнения программы, когда эта про¬ 
цедура производится многократно (с каждым выполнением 
команды), а не однократно, как это осуществляется на более 
ранней стадии (например, на этапе компилирования). Иначе 
говоря, эту проблему можно сформулировать следующим обра¬ 
зом: если в программе на языке высокого уровня указывается 
сложение двух целочисленных переменных, почему бы на этапе 
компилирования не сгенерировать команду целочисленного сло¬ 
жения, вместо того чтобы сначала создавать машинную коман¬ 
ду сложения, инвариантную к типу операндов, а затем на эта¬ 
пе выполнения извлекать содержимое тегов, проверять соответ¬ 
ствие фактических значений операндов их описанию как чис¬ 
ловых данных и использовать эти данные для принятия реше¬ 
ния о выполнении целочисленного сложения? 

Для ответа на этот вопрос необходимо взвесить все «за» и 
«против» теговой памяти, а именно: 1) отмеченные здесь отри¬ 
цательные и рассмотренные выше положительные факторы, 
влияющие на скорость выполнения программ; 2) чрезвычайную 
неэффективность привязки команд к типам операндов на этапе 
выполнения при использовании машин с памятью без тегов и 
наличие в языках программирования конструкций, делающих 
такую привязку желательной; 3) крайне незначительное влияние 
возможных изменений скорости выполнения программ на произ¬ 
водительность системы в целом при существенном проявлении 
нескольких очевидных достоинств теговой организации памяти. 

Принцип теговой организации памяти нельзя считать новым, 
однако вопрос о сравнении скоростей выполнения программ 
традиционными машинами и машинами с теговой памятью до 
сих пор не нашел достаточного освещения в литературе. Можно 
только предположить, что при выполнении программ, не содер¬ 
жащих ошибок, с небольшим числом необходимых преобразо¬ 
ваний данных и фиксируемой на этапе компилирования семан¬ 
тикой выполнения команд машина с теговой памятью работает 
медленнее, чем традиционная машина. Во всех остальных слу¬ 
чаях быстродействие машины с теговой памятью выше. 


ТЕГИ И ДЕСКРИПТОРЫ 

Машина, в которой используются дескрипторы данных, занима¬ 
ет промежуточное положение между машиной с теговой орга¬ 
низацией памяти и традиционной машиной. Дескриптор — это 
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информация о параметрах (атрибутах) данных, играющая 
роль косвенного адреса ячейки памяти с данными. Сравнение 
принципов использования тегов и дескрипторов демонстрирует 
рис. 4.3. В машине, использующей дескрипторы, команды со¬ 
держат ссылки на дескрипторы, несущие информацию об ат¬ 
рибутах данных, которые в свою очередь обычно содержат 
ссылки на адреса областей памяти, хранящих значения операн- 

Пространства 

памяти 



'а *5 

ис. 4.3. Теги (а) и дескрипторы (б) во взаимосвязи 
командами и памятью. 

дов команд. Основные различия между принципами использо¬ 
вания тегов (рис. 4.3, с) и дескрипторов (рис. 4.3,6) заключа¬ 
ются в следующем: 

1. Дескрипторы предполагают наличие дополнительного 
уровня адресации, а следовательно, дополнительного времени 
для предварительной обработки соответствующих адресов и 
дополнительного места в памяти. 

2. Дескрипторы принято рассматривать как часть програм¬ 
мы, а не часть данных. Если полагать, что программа и дан¬ 
ные — это отдельные информационные единицы (как это и 
имеет место при использовании в прикладных программах раз¬ 
деляемых данных, файлов, баз данных и т. п.), то нельзя счи¬ 
тать дескрипторы четко определенными разграничителями ти¬ 
пов этих единиц. Например, очередная прикладная программа 
может описывать пространство данных другими дескрипторами, 
определяющими значения, недействительные согласно определе¬ 
ниям дескрипторов предыдущей программы. 
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3. Согласно п. 2, дескрипторы не позволяют достичь такой 
независимости описания данных, которая возможна при исполь¬ 
зовании тегов. 

4. Согласно п. 2, дескрипторы играют роль некой маски, по¬ 
средством которой можно «рассматривать» содержимое памя¬ 
ти, в то время как теги содержат описание хранимой в намят» 
информации. 

5. Дескрипторы выполняют индексирование линейного про¬ 
странства памяти, т. е. не позволяют отказаться от традицион¬ 
ного представления памяти (попыткам такого отказа, в част¬ 
ности, и посвящена данная глава). 

На основании перечисленного дескрипторы можно рассмат¬ 
ривать как определенный, не лишенный недостатков шаг в на¬ 
правлении создания теговой памяти. В архитектуре большинст¬ 
ва машин, описываемых в данной главе, имеются теги или дес¬ 
крипторы, а в некоторых случаях (например, в ЭВМ В6700 фир¬ 
мы Burroughs) и то и другое. На внешнем уровне архитекту¬ 
ры Системы 38 фирмы IBM используются не теги, а дескрип¬ 
торы. 

НАБОРЫ САМООПРЕДЕЛЯЕМЫХ ДАННЫХ 

Понятие «самоопределяемые данные» можно расширить, если? 
включить в него не только одиночные данные того же вида, но 
и многомерные совокупности этих данных, такие, как массивы,, 

ИМ 1 I 

31111121 20 20 

Рис. 4.4. Дескриптор слова ЭВМ В6700 фирмы Burroughs. 

таблицы, структуры или записи. Хотя для их описания возмож¬ 
но использование тегов, чаще всего для этих целей применяют 
указанные выше дескрипторы. В качестве примера использова¬ 
ния последних рассмотрим описание массивов в вычислитель¬ 
ной системе В6700, имеющей длину слова, равную 51 бит, пер¬ 
вые три бита которого — тег. Если содержимое тега равно 101, 
то данное слово — дескриптор. На рис. 4.4 показан дескриптор 
одного из возможных типов — дескриптор слова. Бит Р указы¬ 
вает, находятся данные в основной памяти или во внешней. 
Бит С предназначен для указания, является ли данный дес¬ 
криптор копией другого дескриптора. Бит I используется для 
указания, описывает ли данный дескриптор всю совокупность 
данных или лишь один элемент этой совокупности. Бит S ука¬ 
зывает, занимают ли описываемые данные непрерывную об¬ 
ласть памяти или же расположены в виде сегментов в ее раз- 
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пых частях. Единичное значение бита R означает, что описывае¬ 
мые данные можно только читать (копировать). Если в рас¬ 
сматриваемом случае биты Т равны 0, то данный дескриптор 
описывает слово, а не строку. Бит D указывает на точность 
(одинарную или двойную) представления описываемых данных. 
Если бит I равен нулю, то следующее за ним поле дескриптора 
определяет число элементов, описываемых дескриптором, а по- 



Рис. 4.5. Представление двумерного массива. 

следнее поле содержит ссылку на начало описываемых данных. 

В системе В6700 дескрипторы могут объединяться в древо¬ 
видные структуры для описания многомерных объектов памяти. 
На рис. 4.5 показана подобная структура в виде массива 3X4 
слов. Дескриптор массива содержит ссылку на 3-элементный 
вектор дескрипторов, который в свою очередь указывает на 
4-элементные векторы слов данных. Одним из следствий такой 
организации является то, что машина ответственна за вычис¬ 
ление индексов элементов массивов и контроль принадлежно¬ 
сти индексов диапазону возможных значений. Для обращения 
к конкретному элементу в программе достаточно указать имя 
дескриптора массива и значения индексов элемента. Машина 
вычисляет адрес нужного элемента и в то же самое время про¬ 
веряет, не выходят ли индексы за границы допустимых значе¬ 
ний. 

В качестве другого примера использования дескрипторов для 
описания массивов может служить вычислительная система 
MU5 ,[6] с дескрипторами двух типов — вектора и строки. Дес¬ 
криптор вектора состоит из трех полей длиной 8, 24 и 32 бит 
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соответственно. Содержимое первого поля определяет длину 
каждого элемента вектора (1, 2, 4, 8, 16, 32, 64 или 128 бит), 
содержимое второго поля — размер вектора (верхнюю границу 
числа элементов), содержимое третьего поля — начало области 
памяти, в которой размещается вектор. Как и в системе В6700, 
здесь элементы вектора сами могут быть дескрипторами. 

Наиболее распространенным видом массива, особенно в за¬ 
дачах нечисленного анализа и делопроизводства, является таб¬ 
лица данных. Обычно под этим термином понимают одномер¬ 
ный массив упорядоченного набора данных, возможно, разно¬ 
родных по типу. Например, определение 10-элементного масси¬ 
ва TAB (каждый элемент которого состоит из 8-символьного и 
целочисленного полей) в программе на языках ПЛ/1 и Ада име¬ 
ет следующий вид: 

DECLARE 1 TAB (10), type PERSON Is 

2 NAME CHAR (8), record 
2 AGE FIXED BINARY; NAME : STRING(1..8); 

AGE: INTEGER; 
end record; 

TAB : array (1.. 10) of PERSON; 

По внешнему виду имена NAME и AGE фрагмента програм¬ 
мы на языке ПЛ/1 ничем не отличаются от имени массивов. 
При использовании же имени NAME в выражении 
TAB.NAME(I) в поле NAME размещается значение Нго эле¬ 
мента массива TAB. 

В системе MU5 наряду с дескрипторами используются по¬ 
добные им по своим функциям фиктивные векторы (dope vec¬ 
tor) для описания массивов с нижним пределом, меньшим 1, и 
столбцов таблиц, именуемых срезами (slices). Фиктивный век¬ 
тор состоит из трех 32-битовых полей. Первые два поля содер¬ 
жат значения нижнего и верхнего пределов, а третье поле — 
значение «шага» — сдвига среза в пределах элемента миссива. 
В приведенных выше фрагментах программ фиктивные векторы 
формируются для имен NAME и AGE. 

Несмотря на существенное сближение принципов организа¬ 
ции памяти систем В6700, MU5 и им подобных с соответствую¬ 
щими элементами структуры языков программирования, воз¬ 
можны и дальнейшие шаги в этом направлении. Например, 
дескрипторы делают «видимой» структуру памяти, предостав¬ 
ляемой элементам массива. От использования дескрипторов, 
можно отказаться и обращаться непосредственно к занимаемой 
массивом области памяти, нарушая тем самым принципы орга¬ 
низации памяти. Стремление к тому, чтобы структура памяти, 
занимаемой массивом, была «видна», накладывает определен¬ 
ные ограничения: элементы массива должны располагаться в 
смежных областях памяти, все строки и все столбцы должны 
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быть одинаковой длины и т. и. К таким ограничениям относит¬ 
ся и отказ от использования одного (общего) тега для всех 
элементов массива (см. предыдущий раздел). Например, в си¬ 
стеме В6700 каждый элемент массива имеет тег, который, сле¬ 
довательно, несет избыточную информацию. 

Стремясь устранить эти недостатки, разработчики системы 
SWARD (часть V) предложили описание массива как данных 
особого типа, отказавшись тем самым от использования дес¬ 
крипторов. Формат ячейки (области) памяти, предоставляемой 
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Рис. 4.6. Ячейка памяти для массива в машине системы SWARD. 


массиву, показан на рис. 4.6. Особый интерес представляет на¬ 
значение двух последних полей. 

Поле вложенного тега — это последнее из полей, которые 
предоставлялись бы тегам, если для устранения избыточности 
они не были бы заменены одним этим тегом согласно подходу, 
рассмотренному в предыдущем разделе. Вместо хранения тега 
с каждым элементом массива атрибуты элементов, т. е. содер¬ 
жимое тегов элементов, определяются в теге массива как часть 
•его содержимого; содержимое этого тега — скалярная величина. 

Последнее поле, изображенное на рис. 4.6, предназначено 
для хранения значений элементов массива и имеет постоянную 
фиксированную длину независимо от размера (числа элемен¬ 
тов) массива. Согласно принципам, заложенным в архитектуре 
системы SWARD, в этом поле должны размещаться все элемен¬ 
ты массива. Однако программе содержимое этого поля «не вид¬ 
но», поэтому создание средств для его формирования вменяет¬ 
ся в обязанность системным программистам — лицам, ответст¬ 
венным за выбор конкретной конфигурации системы и ее во¬ 
площение. В таком случае естественно предположение о целе¬ 
сообразности использования указанного поля не для размеще¬ 
ния элементов массива, а для хранения ссылок на адреса их 
местоположения, что обеспечивало бы косвенную адресацию к 
этим элементам. Однако это означает определенную маскиров¬ 
ку действительного местонахождения элементов массива в па¬ 
мяти. 
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Помимо ячейки памяти для массива, именуемой в системе 
SWARD ячейкой «массив», архитектура SWARD предусматри¬ 
вает использование ячейки памяти другого типа, называемой 
ячейкой «запись» и предназначенной для описания структур 
(записей) и их массивов. Более подробно об этом идет речь в 
части V данной книга. 


ДОСТОИНСТВА НАБОРОВ 
САМООПРЕДЕЛЯЕМЫХ ДАННЫХ 

Как и следовало ожидать, распространение принципа самооп¬ 
ределения данных на такие информационные объекты, как мас¬ 
сивы и структуры, обеспечивает вычислительной системе ряд 
преимуществ, подобных тем, которые проявляются при исполь¬ 
зовании теговой памяти. 

Расширенные возможности обнаружения ошибок. Машина с 
самоопределяемыми данными способна обнаруживать такие 
распространенные ошибки в программе, как использование эле¬ 
ментов массивов с индексами, выходящими за границы допу¬ 
стимых значений. Затраты машинного времени на соответству¬ 
ющую проверку можно считать пренебрежимо малыми по срав¬ 
нению с рассматриваемым ниже выигрышем в скорости выпол¬ 
нения программ. В гл. 2 показано, почему непрактична реали¬ 
зация подобной проверки программными средствами: при ис¬ 
пользовании в программе на языке ПЛ/1 необязательного пара¬ 
метра SUBSCRIPTRANGE для организации указанной провер¬ 
ки оператора 

C(I,J)=A(I,J)+B(J,I); 

Система 370 выполняет 57 команд (вместо 17 без проверки); 
при этом длина машинного кода равна 274 байт (вместо 62). 

Повышенная эффективность выполнения программы. По¬ 
скольку машина выполняет индексирование массивов непосред¬ 
ственно, а не с помощью предназначенного для этих целей ма¬ 
шинного кода, генерируемого компилятором, поиск элементов 
массива осуществляется быстрее, чем в случае использования 
машин с традиционной архитектурой. Это связано главным об¬ 
разом с сокращением числа обращений к памяти за команда¬ 
ми и с уменьшением числа операций по декодированию команд. 
Если принцип инвариантности команд к типу обрабатываемых 
данных распространяется на такие данные, как целые массивы, 
то операции над массивами становятся более эффективными по 
тем же причинам, по которым более эффективны команды, ин¬ 
вариантные к ранее рассмотренным типам данных. Например, 
всем элементам массива можно присвоить определенное значе¬ 
ние, выполнив однократно одну операцию над всем массивов 
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вместо многократного повторения в цикле этой операции над 
каждым элементом. 

Уменьшение необходимого объема памяти. Благодаря пере¬ 
численным выше достоинствам машины с самоопределяемыми 
данными генерируют меньшее количество машинных команд, 
что в свою очередь сокращает объем памяти, необходимый для 
размещения программы. Приведенный выше оператор языка 
ПЛ/1 формирует в Системе 370 семнадцать машинных команд, 
занимающих 62 байт памяти. Большинство этих команд произ¬ 
водится машиной с традиционной архитектурой с целью выпол¬ 
нения операций индексирования массива; эти команды генери¬ 
руются для каждого обращения к массиву, создавая избыточ¬ 
ную информацию в памяти. 

Расширенные возможности реализации системы. Вводя из¬ 
менения в архитектуру системы, разработчик вправе ожидать, 
что использование дополнительных параллельных алгоритмов 
работы системы должно повысить результирующую скорость 
выполнения программ. Примером может служить индексирова¬ 
ние элементов массива. Если, предположим, в смежных обла¬ 
стях памяти размещается двумерный масоив, то обращение к 
его элементу с индексами I и J вызывает обычно вычисление по 
формуле 

Адрес элемента = Базовый адрес массива + ІН — H+J —1. 

Если индексирование элементов массива выполняется непо¬ 
средственно машиной, то возможно совмещение операции умно¬ 
жения с операциями сложения и вычитания. Если же в машине 
предусмотрены команды, инвариантные к типу данных и ори¬ 
ентированные на операции с целыми массивами, то появляется 
возможность параллельной обработки нескольких элементов 
массива. Процессор, располагающий кэш-памятью, может за¬ 
благовременно загрузить буфер необходимой информацией, 
вместо того чтобы запрашивать значение базового адреса при 
выполнении операций над массивом. 

ТЕГИ, ОБЪЕКТЫ И ДЕСКРИПТОРЫ 

В предыдущем и данном разделах демонстрируется разница 
между идентификацией данных посредством тегов и с помощью 
дескрипторов. Введем сопутствующее им понятие «объект». 
О семантическом различии между этими тремя понятиями сви¬ 
детельствуют следующие обстоятельства: в системе В6700 фир¬ 
мы Burroughs тег сопровождает каждое физическое слово па¬ 
мяти, а дескрипторы используются для описания векторов; ар¬ 
хитектура машины SWARD основана на применении тегов и 
объектов; система іАРХ 432 фирмы Intel предполагает иополь- 
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зование объектов и некоторых типов необязательных к упо¬ 
треблению дескрипторов, но исключает применение тегов. 

Объект — это некоторое абстрактное понятие, используемое 
при построении модели вычислительной системы. Обычно объ¬ 
ект принято характеризовать следующим образом: 

1. Объект — это совокупность взаимосвязанных элементов 
информации, которая может включать непосредственно данные, 
сведения о состоянии системы и др. 

2. Элементы или части объекта не могут иметь независимое 
друг от друга «время жизни», т. е. они создаются и уничтожа¬ 
ются одновременно. 

3. К объекту обычно адресуются как к единому целому, а 
не путем индивидуальной адресации его отдельных частей. 

4. Для выполнения преобразований с объектами вычисли¬ 
тельная система располагает некоторым набором машинных 
команд. 

5. Внутренняя структура объекта остается «невидимой» 
(скрытой). 

6. Объект содержит идентифицирующую его информацию 
(информацию самоидентификации), запрещающую программе 
выполнять операции над объектом другого, отличного от данно¬ 
го типа. 

В этих характеристиках объекта программисты могут найти 
много общего с понятием «абстрактные данные», хотя в рас¬ 
сматриваемом случае возникновение абстрактного понятия 
«объект» связано с машиной. Например, в рамках систем 
SWARD « іАРХ 432 существует объект, именуемый порт. Объ¬ 
ект такого типа используется для пересылки данных от одного 
процесса (задания) к другому. Внутренняя структура объекта 
«порт» программу «не интересует»; она оперирует им как опе¬ 
рандом, адресуясь к нему как к набору машинных команд. 

Возможную взаимосвязь данных тегового типа и объектов 
можно увидеть в принципах, положенных в основу архитекту¬ 
ры SWARD. Здесь объектом может быть содержимое одной 
ячейки данных тегового типа или набора таких ячеек, а также 
совокупность какой-либо другой информации, исключающей со¬ 
держимое ячеек данных. Машина позволяет программе динами¬ 
чески разрешать использование данных определенного типа 
(аналогично тому, как это делают оператор ALLOCATE языка 
ПЛ/1 или средства описания типов данных языка Ада для со¬ 
здания массива, строки, записи, одиночного целого числа и 
т. д.). Такая возможность использования данных называется 
объектом «данные», поскольку это — одиночная ячейка данных, 
«время жизни» которой не зависит от других ячеек данных. 
Объект другого типа — «модуль» — содержит машинные коман¬ 
ды, набор ячеек данных тегового типа (для любых статических 
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или собственных переменных, используемых этими командами) 
и другую информацию о состоянии системы. Объект «порт» яв¬ 
ляется примером объекта такого типа, который не содержит 
ячеек данных. 

ОБЛАСТИ 

САНКЦИОНИРОВАННОГО ДОСТУПА 

Архитектуре современных машин присущи негибкие и грубые 
средства защиты данных от несанкционированного доступа; в 
большинстве микропроцессоров такие средства вообще отсутст¬ 
вуют. Обычно указанные средства используются для защиты 
данных и программного обеспечения системы (например, опера¬ 
ционной системы) от модификации или инспекции прикладными 
программами, а также одной прикладной программы от несанк¬ 
ционированного доступа со стороны другой прикладной про¬ 
граммы. Однако такие средства не обеспечивают защиту, во- 
первых, программы (процесса) от самой себя или, говоря 
точнее, одной программной секции (например, процедуры) от 
другой и, во-вторых, программы от программного обеспечения 
системы. Поэтому было предложено формирование небольших 
областей санкционированного доступа — доменов — с целью 
достижения большей детальности расчленения всего адресного 
пространства системы на зоны, защищенные от несанкциониро¬ 
ванного доступа. Речь идет как о защите от случайных обра¬ 
щений извне или от программных ошибок, так и от преднаме¬ 
ренных обращений, защита от которых определяется требова¬ 
ниями конфиденциальности хранимой в машине информации. 
Область санкционированного доступа —это независимое ло¬ 
кальное адресное пространство, определяющее совокупность 
адресов, которые могут использоваться или формироваться не¬ 
которым набором команд [7—10]. Небольшая область санкцио¬ 
нированного доступа (называемая, как указано выше, доме¬ 
ном) предполагает разбиение всего адресного пространства на 
некоторое, весьма значительное число более мелких локальных 
адресных пространств, когда на одну прикладную программу 
(или процесс) либо программу операционной системы прихо¬ 
дится не одна, а несколько таких областей. 

Появилась идея предоставления каждой программной сек¬ 
ции одного такого домена. Определение понятия программная 
секция зависит от принципа адресации и допустимого набора 
идентификаторов конкретного языка программирования (при 
этом архитектура вычислительной системы должна быть доста¬ 
точно гибкой для адаптации к различиям языков программиро¬ 
вания). Как правило, программная секция определяется как 
независимо компилируемая программная единица (пакет, про- 
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цедура, подпрограмма, программа-монитор и т. п.). Поэтому 
вместо размещения программы полностью в одном большом ад¬ 
ресном пространстве (т. е. одном подпространстве адресного 
пространства системы) каждому модулю предоставляется от¬ 
дельное адресное пространство, доступное только его локаль¬ 
ным переменным. А это влечет за собой проблему организа¬ 
ции связи между доменами, которая решается с помощью ме¬ 
ханизма управления подпрограммами (описываемого в сле- 


Рис. 4.7. Два домена 
санкциониров энного 
доступа. 


дующем разделе), регулирующего процесс обмена информаци¬ 
ей между формальными и фактическими параметрами. Переда¬ 
чу фактических параметров подпрограмме, занимающей неко¬ 
торый домен, можно рассматривать как временное расширение 
ими этого домена (рис. 4.7). В идеальном случае домен В рас¬ 
ширяется только на время передачи ему из домена А фактиче¬ 
ских параметров (поскольку домен В не имеет адресных свя¬ 
зей с какими-либо иными элементами домена А), и это расши¬ 
рение исчезает с возвратом управления от В к А. 

Понятие домена часто сопровождается понятием «точка 
санкционированного входа». В пределах каждого домена про¬ 
граммисту может быть предоставлена возможность определе¬ 
ния одной или нескольких специфических точек входа, которые 
исключают возможность вызова модуля, расположенного в до¬ 
мене, путем обращения к любой его команде. 

ДОСТОИНСТВА ИСПОЛЬЗОВАНИЯ ДОМЕНОВ 

Улучшение отладки программ. Разбиение адресного простран¬ 
ства программы на домены, предоставляемые отдельным про¬ 
граммным секциям, повышает степень локализации возможных 
ошибок. В машине, имеющей традиционную архитектуру, ошиб¬ 
ка адресации может оказать воздействие на любую часть про¬ 
граммы, а ошибка, содержащаяся в одной части операционной 
системы, может повлиять на работу других ее частей или при¬ 
кладные программы. В машине с разбиением адресного прост¬ 
ранства на домены сфера действия возможной ошибки ограни¬ 
чена пределами домена, в котором она находится (включая лю- 
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бые расширения данного домена за счет передачи в него фак¬ 
тических параметров). А это повышает вероятность обнаруже¬ 
ния ошибки на более ранней стадии выполнения программы и, 
что также важно, в «точке» ее возникновения. 

Повышение надежности защиты программы от несанкцио¬ 
нированного доступа. Благодаря доменам информация, принад¬ 
лежащая одной части программы или процесса, защищена от 
воздействия других ее частей. Таким образом, обеспечивается 
защита от несанкционированного доступа, отсутствующая в 
традиционных машинах. Принцип доступа модуля только к тем 
данным, которые необходимы для его функционирования, мо¬ 
жет быть назван принципом наименьших привилегий. 

В подобных средствах защиты от несанкционированного до¬ 
ступа нуждаются программы, состоящие из секций различного 
уровня требуемой надежности подобной защиты, или програм¬ 
мы, обращающиеся за обслуживанием к другим программным 
средствам (например, к программам операционной системы 
или модулям пакета подпрограмм), имеющим другой уровень 
надежности защиты. Предположим, что модуль А (рис. 4.7) со¬ 
держит «чувствительные» к несанкционированному доступу 
данные и нуждается для выполнения какой-то работы в обра¬ 
щении к модулю В. Последний либо принадлежит другому про¬ 
граммисту, либо является частью подпрограмм общего назна¬ 
чения, либо включен в набор программ операционной системы. 
Проблема защиты данных может возникнуть, поскольку суще¬ 
ствует вероятность того, что модуль В является как бы троян¬ 
ским конем, т. е. чужой программой с «замаскированными на¬ 
мерениями», вводимой внутрь «крепостных стен» модуля А. 
Если в результате вызова модуля В последний получает до¬ 
ступ ко всем данным модуля А, то, выполняя требуемые от не¬ 
го функции, модуль В может анализировать данные модуля А, 
нуждающиеся в защите от подобного доступа. Если адресное 
пространство разделено на домены, возможности адресации мо¬ 
дуля В ограничены только фактическими параметрами, пере¬ 
даваемыми ему при вызове. 

Механизм защиты от несанкционированного доступа посред¬ 
ством доменов применим и к вызываемым модулям. Например, 
модуль В может содержать нуждающиеся в защите данные, 
формируемые в виде некоторой базы данных в периоды вызова 
модуля В другими модулями, например модулем А. При от¬ 
сутствии областей, защищенных от несанкционированного до¬ 
ступа, не исключается возможность для модуля А, имеющего 
адрес точки входа в модуль В, выполнить арифметические опе¬ 
рации над этим адресом и получить доступ к «секретным» дан¬ 
ным модуля В. Возможна также и следующая ситуация не¬ 
санкционированного доступа при отказе от использования доме- 
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нов: модуль А, получив назад управление от вызывавшегося 
модуля В, просматривает адресное пространство стека подпро¬ 
грамм с целью анализа значений локальных переменных моду¬ 
ля В. 

Принудительное разбиение программ на модули. Известно 
(например, [11]), что простое разбиение программы на отдель¬ 
ные модули не обязательно приводит к реализации всех пре¬ 
имуществ модульного программирования. Разбиение програм¬ 
мы на отдельные модули иногда сопровождается отступления¬ 
ми от общепринятых правил взаимодействия модулей явным 
образом через списки параметров. Так, при стремлении до¬ 
биться хорошо структурированной программы в некоторых слу¬ 
чаях допускается прямой доступ из одного модуля к данным 
другого модуля. Использование механизма защиты от несанк¬ 
ционированного доступа с помощью доменов позволяет исклю¬ 
чить указанные нарушения правил обмена информацией между 
модулями и, следовательно, обеспечить корректность разбиения 
программы на модули, причем такое разбиение, как правило, 
бывает неизбежным. 

Разбиение адресного пространства машины на домены 
предъявляет к ее архитектуре ряд требований, не являющихся 
очевидными на первый взгляд. Например, требуется механизм, 
гарантирующий вызванному модулю, получившему доступ к 
фактическому параметру, невозможность доступа к другим дан¬ 
ным домена, в котором этот параметр находится. Другим тре¬ 
бованием является гарантия входа в модули только через опре¬ 
деленные точки входа. Более подробно эти вопросы освещают¬ 
ся в части V (архитектура SWARD), а также в технической ли¬ 
тературе, содержащей описание еще одного типа архитектуры 
с доменами [12], средств передачи фактических параметров 
[13] и реализации доменов программными средствами в ЭВМ 
PDP-11 і[8]< 

УПРАВЛЕНИЕ ПОДПРОГРАММАМИ 

Важным шагом на пути дальнейшего сокращения семантиче¬ 
ского разрыва между архитектурой машины и языком програм¬ 
мирования является отображение структуры программы в ар¬ 
хитектуре машины, причем особое значение имеет соответствие 
архитектуры средствам организации подпрограмм или проце¬ 
дур, используемым программами. Необходимость в этом обу¬ 
словлена тем, что указанные средства в традиционных машинах 
реализуются программным путем, что является весьма про¬ 
должительным процессом. Например, при обращении к проце¬ 
дуре в типичной программе на языке высокого уровня соответ¬ 
ствующий этой программе объектный код, генерируемый ком- 
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пилятором, должен выполнить следующие действия: динамиче¬ 
ски (т. е. в момент вызова) выделить в памяти область, назы¬ 
ваемую «запись активации» и предназначенную для размеще¬ 
ния локальных переменных и информации о состоянии вызван¬ 
ной процедуры; добавить эту запись к поддерживаемому про¬ 
граммными средствами стеку записей активации для данной 
программы; записать информацию о состоянии вызывающей 
процедуры на хранение в ее запись активации; присвоить на¬ 
чальные значения содержимому локальной памяти и парамет¬ 
рам вызываемой процедуры; передать управление вызываемой 
процедуре. Как отмечено в гл. 2, этот процесс выполняется 
весьма часто и, следовательно, является предметом изучения 
соотношений между средствами аппаратного и программного 
обеспечения. Согласно результатам исследований ;[14, 15], на 
каждые 50—100 машинных команд имеет место один вызов 
подпрограммы. 

Сокращение указанного семантического разрыва предпола¬ 
гает такую модификацию архитектуры традиционной машины, 
которая позволила бы реализацию аппаратными средствами 
некоторых или всех перечисленных функций. Как и в случае 
модификации других сторон взаимоотношений аппаратных 
средств и программного обеспечения с целью сокращения се¬ 
мантического разрыва между ними, здесь возможна различ¬ 
ная степень уменьшения этого разрыва. Ограничим рассмотре¬ 
ние двумя подходами. При первом подходе существенного из¬ 
менения традиционной модели памяти машины не требуется, 
но предполагается введение команд, помогающих реализовать 
средства организации подпрограмм. При втором подходе ука¬ 
занная модель меняется и память более «похожа» на ее пред¬ 
ставление в языках программирования. Пользуясь понятием 
«стек активации», первый подход можно было бы определить 
как применение видимого ( явного ) стека активации, а вто¬ 
рой — применение скрытого ( неявного) стека активации. 

Для первого подхода характерно использование, во-первых, 
способов адресации, допускающих в памяти существование уп¬ 
равляемых группой программ стеков магазинного типа с отно¬ 
сительной адресацией внутри каждого стека, и, во-вторых, ко¬ 
манд, позволяющих программе управлять своим стеком при пе¬ 
редаче параметров, возврате адресов и выделении памяти для 
локальных переменных. Примером такого подхода является 
микропроцессор 68000 фирмы Motorola, содержащий восемь 
32-битовых регистров данных и восемь 32-битовых адресных 
регистров. Один из адресных регистров — А7 — неявно адресу¬ 
ется небольшим числом команд и известен под названием ука¬ 
затель стека (SP). Обычно при организации подпрограмм еще 
один адресный регистр используется как указатель кадра (FP). 
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Микропроцессор 68000 располагает многочисленными спосо¬ 
бами адресации, т. е. способами формирования командами ад¬ 
ресов памяти, а его команды отличаются высокой степенью ин¬ 
вариантности к способу адресации (большинство команд допу¬ 
скает любой способ адресации из числа возможных). Речь идет 
о следующих способах адресации: абсолютной, косвенной ре¬ 
гистровой, посредством регистра базы и смещения (положи¬ 
тельного или отрицатель¬ 
ного) , косвенной регист¬ 
ровой с априорным отри¬ 
цательным или апостери¬ 
орным положительным 
единичным приращением fp 
содержимого регистра, 
посредством индексиро¬ 
вания и заданием адреса 
относительно значения SP 
счетчика команд. 

Обычно в стеке акти¬ 
вации, устанавливаёмом 
в памяти для процесса, 
содержится некоторое ко¬ 
личество кадров (после¬ 
довательностей слов в 
стеке). Кажідый кадр 
представляет собой за¬ 
пись активации для ак¬ 
тивной подпрограммы, F 
содержащую место для д 
локальных переменных, 
адрес возврата, место для 
записываемого на хране¬ 
ние содержимого регистров и для фактических параметров, ис¬ 
пользуемых для обращения к другой подпрограмме. Естествен¬ 
ным является такое состояние, при котором указатель кадра 
содержит адрес начала текущего (расположенного на вершине 
стека) кадра или записи активации, а указатель стека содер¬ 
жит адрес вершины стека (последнего слова в текущем кадре). 
Адресация посредством регистра базы и смещения может быть 
использована для адресации памяти в пределах кадра (т. е. от¬ 
носительно указателя кадра), а косвенная регистровая адреса¬ 
ция с априорным отрицательным или апостериорным положи¬ 
тельным приращением содержимого регистра применяется для 
загрузки информации в стек или извлечения ее оттуда (т. е. 
запись текущего кадра в стек или извлечение его из стека). 

Для анализа процесса использования подпрограмм семейст- 
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вом микропроцессоров 68000 предположим, что в данный мо¬ 
мент выполняется процедура А, причем текущее состояние сте¬ 
ка соответствует тому, что изображено на рис. 4.8, а. (Способы 
адресации определены таким образом, что увеличение стека 
происходит путем расширения занимаемой им области памяти 
в сторону меньших по номеру адресов.) Пусть процедуре А 
нужно вызвать процедуру В, для чего используется оператор 
CALL В(7,Х), реализуемый четырьмя командами процедуры А. 
Первой является команда MOVE с косвенной регистровой адре¬ 
сацией посредством априорного отрицательного приращения со¬ 
держимого указателя стека; она помещает число 7 на вершину 
стека. (Предполагается, что число 7 подлежит передаче по зна¬ 
чению.) Вторая команда — команда PUSH EFFECTIVE 
ADDRESS — используется для загрузки адреса переменной X 
на вершину стека (эта переменная подлежит передаче 
путем ссылки на нее). Третья команда — команда JUMP ТО 
SUBROUTINE — загружает в стек адрес возврата (адрес сле¬ 
дующей команды) и изменяет содержимое счетчика команд. 
Четвертая команда, выполняемая после возврата из процеду¬ 
ры В, — это команда ADD, которая добавляет число 4 (два 
слова) к содержимому указателя стека и тем самым осущест¬ 
вляет удаление фактических параметров из стека. 

Процедура В начинается с выполнения команды LINK. Ес¬ 
ли для локальных переменных процедуры В требуется 24 байт 
памяти, то эта команда имеет вид LINK FP.24. В процессе вы¬ 
полнения она, во-первых, загружает в стек текущее содержимое 
указателя кадра, тем самым сохраняя в данном кадре адрес 
предыдущего кадра; во-вторых, записывает текущее содержи¬ 
мое указателя стека в указатель кадра и, в-третьих, увеличива¬ 
ет на 24 содержимое указателя стека. По второй команде про¬ 
цедуры В —команде MOVE MULTIPLE REGISTERS — в стек 
загружается содержимое любых регистров, используемых этой 
процедурой. Теперь стек имеет вид, подобный тому, который по¬ 
казан на рис. 4.8,6. Локальные переменные процедуры В адре¬ 
суются посредством отрицательного смещения относительно по¬ 
ложения указателя кадра, а фактические параметры — посред¬ 
ством положительного смещения относительно этого же указа¬ 
теля. Завершается процедура В тремя командами. По первой 
команде — MOVE MULTIPLE REGISTERS — восстанавливает¬ 
ся содержимое указанных регистров путем извлечения его из 
стека. По второй команде — UNLINK — содержимое указателя 
кадра помещается в указатель стека, а затем текущее содержи¬ 
мое вершины стека (адрес предыдущего кадра) загружается 
в указатель кадра. Последняя команда — RETURN FROM 
SUBROUTINE — служит для размещения содержимого верши¬ 
ны стека в счетчике команд. 
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Хотя при использовании подобного механизма функциониро¬ 
вания подпрограмм значительная часть нагрузки по управле¬ 
нию подпрограммами снимается с «плеч» компиляторов, одна¬ 
ко такому способу организации подпрограмм присущи следую¬ 
щие недостатки: 

1. Сохранение подобного механизма как единого целого за¬ 
висит от того, насколько взаимодействующие процедуры подчи¬ 
няются протоколу их взаимодействий, определяемому програм¬ 
мой. Любое отклонение от принятых соглашений (в частности, 
несоответствие между числом передаваемых фактических пара¬ 
метров и «ожидающих» их формальных, неудача в попытке ис¬ 
пользования обеими процедурами одного и того же адресного 
регистра ів качестве указателя кадра, выделение неправильного 
объема памяти посредством команды LINK, неудача в попытке 
сохранения и восстановления содержимого необходимых реги¬ 
стров) может неожиданно привести к неудаче в выполнении 
программы. 

2. При реализации данного механизма новая модель памя¬ 
ти не является в большей степени адекватной модели памяти, 
используемой языками программирования. Команды вызывае¬ 
мой процедуры могут модифицировать 'информацию в стеке, 
описывающую состояние системы, и имеют доступ к кадрам 
стеков других процессов. Таким образом, не достигается защи¬ 
та от несанкционированного доступа, обеспечиваемая описан¬ 
ными выше средствами защиты доменами. 

3. Если при входе в процедуру локальным переменным необ¬ 
ходимо задавать начальные значения, то требуются дополни¬ 
тельные команды. 

4. Структуре стека присущ последовательный принцип орга¬ 
низации, поэтому его максимальный размер должен быть оп¬ 
ределен заблаговременно для каждого процесса и для каждого 
стека должна быть заранее зарезервирована память из расчета 
на его максимально возможный размер. 

Эти недостатки нетрудно устранить, если «спрятать» сред¬ 
ства функционирования стека в машине и создать средства 
управления подпрограммами более высокого уровня в архитек¬ 
туре вычислительной системы. Именно так и поступили разра^ 
ботчики архитектуры системы SWARD. В этом случае каждая 
прошедшая компилирование программная единица представле¬ 
на машинным объектом, получившим название «модуль». Мо¬ 
дуль — это совокупность ячеек теговой памяти и машинных ко¬ 
дов, представляющих одну или несколько процедур. Ячейки 
можно разделить на две группы. К первой группе относятся 
ячейки, динамически выделяемые в качестве новых элементов 
при вызове модуля. Вторая группа объединяет ячейки, «время 
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жизни» которых не зависит от обращений к модулю. (Такими 
ячейками являются, например, статические или собственные 
переменные.) На этапе компилирования каждой ячейке может 
быть присвоено начальное значение. 

Для обращения к входной точке процедуры модуля исполь¬ 
зуется команда CALL, по внешнему виду очень похожая на опе¬ 
ратор CALL языков программирования. Операндами этой 
команды являются адрес точки входа процедуры в модуле и 
список фактических параметров. Команда CALL выполняет 
следующие действия: 

1) запись на хранение состояния выполняемого модуля (на¬ 
пример, запоминание адреса возврата в этот модуль); 

2) выделение в памяти места для записи активации, пред¬ 
назначенной для вызываемого модуля, и копирование туда со¬ 
держимого всех ячеек вызываемого модуля, для которых хотят 
получить новое содержимое; 

3) пуск вызываемого модуля на выполнение. 

Первой выполняемой командой вызванного модуля обычно 
является команда ACTIVATE, которая перечисляет в качестве 
своих операндов имена ячеек, получающих метки (теги), как 
ячейки формальных параметров. Команда ACTIVATE заставля¬ 
ет машину проверять каждый формальный параметр и соответ¬ 
ствующий ему фактический .параметр на согласование по типу 
(для чего используются теш), а также устанавливает ссылку 
формального параметра на соответствующий фактический. 
Команда RETURN отменяет все назначения, выполненные 
командой CALL. 

Подобный способ управления подорограм.мами отличает¬ 
ся от рассмотренного выше тем, что признаки его существова¬ 
ния крайне незначительно отображены в архитектуре вычисли¬ 
тельной системы. Хотя в спецификации архитектуры упомина¬ 
ется о наличии записи активации и стека этих записей, однако 
их фактический формат, местоположение и механизм взаимосвя¬ 
зей (например, как элементов последовательной и списковой 
структур) известны только тому, кто несет ответственность за 
практическую реализацию машины, и, следовательно, они мо¬ 
гут изменяться при переходе от одной реализации к другой. 
Единственное, что доступно программисту или разработчику 
компилятора, — это команды CALL, ACTIVATE и RETURN; ха¬ 
рактер распределения памяти, формальные параметры со ссыл¬ 
ками на соответствующие им фактические параметры и др. 
скрыты за «фасадом» архитектуры. Действия программы не мо¬ 
гут разрушить целостность этого механизма. Невозможно, на¬ 
пример, возникновение непредвиденных передач управления, 
модификация информации о взаимосвязи модулей и т. л. По¬ 
добный механизм предусматривает также и защиту от несанк- 
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ционированного доступа посредством доменов: каждый мо¬ 
дуль — это домен. 


ДОСТОИНСТВА ИСПОЛЬЗОВАНИЯ 
СРЕДСТВ УПРАВЛЕНИЯ ПОДПРОГРАММАМИ 

Повышенная эффективность выполнения программы. Как и при 
других подходах к решению подобных проблем, предполагаю¬ 
щих перекладывание некоторых или всех функций управления 
подпрограммами на машинный интерфейс (т. е. осуществление 
интерфейса между подпрограммами на машинном уровне), в 
данном случае тоже достигается повышенное быстродействие 
благодаря более эффективному использованию потенциальной 
пропускной способности тракта «процессор — память». А по¬ 
скольку рассматриваемый подход усиливает тенденцию к более 
глубокому структурированию (повышенной модульности) про¬ 
грамм, то отмеченное достоинство становится еще более важ¬ 
ным. 

Уменьшение необходимого объема памяти. Как и в других 
ситуациях, влекущих за собой усиление роли машинного ин¬ 
терфейса, при использовании рассматриваемых средств управ¬ 
ления подпрограммами сокращается размер программ и умень¬ 
шается объем генерируемых компилятором кодов, которые не¬ 
обходимы для реализации вызовов подпрограмм. 

Расширенные возможности обнаружения ошибок. При сов¬ 
местном использовании теговой памяти и средств управления 
подпрограммами (как это имеет место в системе SWARD) ма¬ 
шина может обнаруживать ошибки работы интерфейса. На¬ 
пример, она может выявить, что вместо ожидаемых пяти фак¬ 
тических параметров подпрограмма получает только четыре или 
вместо числа с плавающей точкой ей передается строка симво¬ 
лов. Альтернативой такого решения является осуществление 
подобного необходимого контроля программными средствами до 
выполнения, например на этапе редактирования и установле¬ 
ния связей между модулями или в процессе компилирования, 
как это происходит при использовании языка Ада. Хотя целе¬ 
сообразность такого контроля очевидна, не все ошибки интер¬ 
фейса могут быть обнаружены до выполнения программы. Это 
объясняется следующими причинами. 

Во-первых, в некоторых программах атрибуты фактических 
параметров не известны до наступления этапа ее выполнения. 
Так, процедура во время своей работы принимает решение, ка¬ 
кие фактические параметры должны быть переданы. Во-вто¬ 
рых, обычно в вычислительной системе имеются интерфейсы 
(например, обеспечивающие запрос функций операционной си¬ 
стемы), остающиеся не подсоединенными на этапе редактиро- 
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вания и установления связей. В-третьих, некоторые системы и 
языки программирования предостаівляют возможность динами¬ 
ческого установления связей между вызывающими и вызывае¬ 
мыми программными модулями на этапе выполнения. В-чет- 
вертых, в некоторых ситуациях до момента выполнения не из¬ 
вестно, какая процедура будет вызвана конкретным операто¬ 
ром CALL. Это происходит, в частности, при использовании в 
программах на языке ПЛ/1 переменных, задаваемых операто¬ 
ром ENTRY. 

Расширенные возможности реализации системы. Более ши¬ 
рокое применение машинного интерфейса предоставляет разра¬ 
ботчику процессора дополнительные возможности по организа¬ 
ции параллельных вычислительных операций с помощью аппа¬ 
ратных средств. Так, можно одновременно выделить память 
для записи активации с целью хранения состояния вызываю¬ 
щей процедуры и провести проверку формальных и фактиче¬ 
ских аргументов на соответствие типов. С учетом большой веро¬ 
ятности весьма частого обращения вызываемой процедуры к 
ячейкам в своей записи активации последняя (или наибольшая 
возможная ее часть) может получить место непосредственно в 
быстродействующем буфере, или кэш-буфере. Поскольку даже 
в мультипроцессорной системе записи активации процесса яв¬ 
ляются локальными по отношению к процессу, процессору мож¬ 
но «не заботиться» о выполнении операций промежуточных за¬ 
писей в кэш-буфер записи активации. 

ПОТЕНЦИАЛЬНАЯ АДРЕСАЦИЯ 

Еще одним важным шагом в направлении сокращения семанти¬ 
ческого разрыва между машинным интерфейсом и окружающим 
его программным обеспечением и, следовательно, улучшения 
примитивной модели памяти архитектуры фон Неймана явля¬ 
ется введение принципа потенциальной адресации (capability- 
based addressing). Как и другие подобные нововведения, по¬ 
тенциальная адресация может быть реализована с различной 
степенью использования скрытых в ней возможностей. Далее 
рассматривается один из ее расширенных, т. е. модифициро¬ 
ванных, видов. 

Прежде всего при данном подходе отказываются от такой 
модели памяти, при которой последняя представляется как ли¬ 
нейная последовательность слов. Вычислительную систему рас¬ 
сматривают как единый набор объектов. В определение «еди¬ 
ный» вкладывается следующий смысл: отсутствуют какие-либо 
заранее предопределенные границы адресуемости, т. е. «всё» 
потенциально адресуемо «всеми». Термин «набор» предполагает 
отсутствие определенного упорядочения объектов, т. е. отсутст- 
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вует такое понятие, как «один объект является следующим по 
отношению к другому». Выше указывалось, что термин «объ¬ 
ект» символизирует группу взаимосвязанных элементов памя¬ 
ти с одинаковым «временем жизни», т. е. элементы создаются и 
уничтожаются совместно. В зависимости от разновидности ар¬ 
хитектуры объект может быть столь же примитивным, как и 
сегмент памяти (самостоятельной по своему функциональному 
назначению линейной по¬ 
следовательностью слов, 
внутренняя структура ко¬ 
торой по виду подобна 
традиционной памяти фон 
Неймана), или некоторой 
абстракцией, физическая 
форма которой скрыта 
за «фасадом» архитекту¬ 
ры, а назначение опреде¬ 
ляется теми преобразова¬ 
ниями, которым она мо¬ 
жет подвергаться. 

На рис. 4.9 схемати¬ 
чески изображена рас¬ 
сматриваемая модель па¬ 
мяти. Стрелки показыва¬ 
ют возможные обраще¬ 
ния одного объекта к другому, т. е. свидетельствуют о наличии 
имен и адресов одних объектов внутри других. Следует обра¬ 
тить внимание, что эта модель включает все составные элемен¬ 
ты вычислительной системы независимо от того, является ли 
последняя системой одного пользователя или многих. Каждый 
объект потенциально адресуем любым другим объектом, но 
такая адресация не устанавливается автоматически и не может 
быть создана односторонне. Это положение является основопо¬ 
лагающим при формировании понятия «потенциальная адре¬ 
сация». 

На данном этапе рассуждений не представляется целесо¬ 
образным углубляться в природу объектов, поскольку она мо¬ 
жет меняться при переходе от одной архитектуры к другой. Од¬ 
нако можно-воспользоваться, например, такими терминами, как 
объект «программа» и объект «данные». (При рассмотрении 
архитектуры конкретной системы появятся объекты и других 
типов.) Объект «программа» может представлять собой после¬ 
довательность команд и, возможно, набора локальных перемен¬ 
ных. Например, объект «программа» может соответствовать 
процедуре языка ПЛ/1, пакету программ языка Ада или про¬ 
граммному модулю. Объект «данные» может отображать дина- 
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мически выделяемую память для новой переменной, т. е. па¬ 
мять, «создаваемую» описателями типов переменных языка 
Ада. В качестве других примеров объектов можно указать на 
оправочники адресов и файлы. Рассматриваемая модель памя¬ 
ти предполагает, что все объекты «программа» и объекты «дан¬ 
ные» потенциально адресуемы друг другом, и это является ос¬ 
новой для использования принципа разделения ресурсов про¬ 
грамм и данных. В то же время утверждение о том, что адре¬ 
суемость не является неявной и не может быть установлена од¬ 
носторонне, предполагает наличие средств защиты от несанк¬ 
ционированного доступа. 

Объекты могут создаваться только с участием машины, т. е. 
посредством машинных команд. Имя сформированного объекта 
передается «создателю» объекта (имя есть результат работы 
машинной команды, выполняемой с целью создания объекта). 
Согласно принципу потенциальной адресации, имя объекта 
не связано с адресом возможного местоположения объекта. 
Имя объекта отображает адрес только в логическом, но не в 
физическом смысле этого слова. Информацию, необходимую 
для преобразования имени объекта в физический адрес его ме¬ 
стоположения, содержит машина. Следовательно, имя объек¬ 
та— это некоторая совокупность битов, назначение которых из¬ 
вестно только машине. 

При создании объектов машина присваивает им уникальные 
имена — имена, которые никогда не назначались другим объек¬ 
там и не подлежат использованию для других объектов в даль¬ 
нейшем. Ниже будут сформулированы доводы в пользу при¬ 
своения объектам таких имен. Конечно, употребление слова 
«никогда» в данном контексте нельзя назвать абсолютно точ¬ 
ным, поскольку в этом случае имена содержали бы бесконечно 
большое количество битов. В действительности используются 
имена фиксированной (конечной) длины, однако достаточно 
большой для обеспечения уникальности имен в пределах ожи¬ 
даемого «времени жизни» системы. Например, 48-битовые име¬ 
на допускают разнообразие уникальных имен, оцениваемое ве¬ 
личиной, которая превышает ІО 16 . 

Установление потенциальной адресуемости предполагает 
появление одного из этих имен, и поэтому потенциальный адрес 
подобен обычному адресу по форме и способам использования. 
Функционирование механизма потенциальной адресации бази¬ 
руется на защите существующих потенциальных адресов и за¬ 
прете создания других подобных адресов. Защита потенциаль¬ 
ных адресов означает запрет программе модифицировать уста¬ 
новленную потенциальную адресацию, например манипулиро¬ 
вать потенциальным адресом одного объекта так, как будто он 
относится к другому объекту. Запрет создания потенциальных 
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адресов означает предотвращение ситуаций, позволяющих про¬ 
грамме генерировать потенциальный адрес, подобно тому как 
она это делает в машинах традиционной архитектуры; програм¬ 
ма может «завладеть» потенциальным адресом только путем 
создания объекта или получением его от другой программы. 
Эти основные правила могут быть подкреплены либо требова¬ 
нием хранения потенциальных адресов только в специальных 
«защищенных» объектах (списках потенциальных адресов), ли¬ 
бо спецификацией потенциальных адресов как данных тегового 
типа, а затем введением ограничений на типы операций, кото¬ 
рые могут выполняться над такими потенциальными адресами. 

Перечисленные основные правила показывают, как потен¬ 
циальная адресация обеспечивает защиту в модели памяти, ко¬ 
торая предполагает потенциальную адресуемость любого объ¬ 
екта. Адресуемость (доступ к объектам) управляется регулиро¬ 
ванием распределения потенциальных адресов. Непременным 
условием возможности обращения к объекту является владение 
его потенциальным адресом, а подобные адреса нельзя ни со¬ 
здавать, ни модифицировать. Такой механизм защиты объектов 
от несанкционированного доступа можно сравнить со следую¬ 
щей физической моделью реального мира: все объекты — сун¬ 
дуки с замками, а потенциальные адреса — ключи к ним. Тот, 
кто делает новый сундук, получает к нему ключ. Ключи можно 
дублировать («делать копии») и передавать во владение дру¬ 
гим, но нельзя видоизменять или подделывать. 

Описываемый механизм защиты может быть усовершенство¬ 
ван за счет сочетания потенциального адреса с директивной ин¬ 
формацией на право доступа к объекту. В этом случае потен¬ 
циальный адрес — это не просто имя или логический адрес 
объекта, а сочетание подобного логического адреса с индика¬ 
тором права на доступ. В качестве примера введем понятия 
«доступ к чтению» (возможность пользоваться информацией, 
содержащейся в объекте), «доступ к записи» (возможность 
записывать информацию в объект или модифицировать храни¬ 
мую там информацию), «доступ к уничтожению» (возможность 
уничтожить данный объект). При создании объекта машина пе¬ 
редает тому, кто его создал, потенциальный адрес с правом 
полного доступа (т. е. доступа к чтению, записи и уничтоже¬ 
нию). Предположим, что существует команда, позволяющая 
ограничить потенциальный адрес доступом определенного вида. 
Например, процесс А может создать объект X, сделать копию 
полученного потенциального адреса, удалить из этой копии до¬ 
ступ к записи и уничтожению и передать такую копию про¬ 
цессу В, снабдив тем самым этот процесс возможностью по¬ 
тенциальной адресации к указанному объекту, однако эта воз¬ 
можность ограничена только доступом к чтению. 



Обратимся еще раз к физической аналогии рассматриваемо¬ 
го механизма защиты от несанкционированного доступа: каж¬ 
дый сундук имеет несколько крышек. Когда открыта одна 
крышка, то через прозрачный экран перед нами предстает со¬ 
держимое сундука (т. е. имеет место доступ к чтению); откры¬ 
вание второй крышки позволяет попасть внутрь сундука, но это¬ 
му предшествует отключение внутреннего освещения (так реа¬ 
лизуется доступ к записи); при открывания третьей крышки 
становится доступной клавиша, нажатие которой приводит к 
уничтожению сундука (таким путем осуществляется доступ к 
уничтожению). Тип доступа определяет конкретный рисунок 
профиля (бородки) ключа; для каждой крышки этот рисунок 
является своим. Рисунок может быть стерт (бородка на ключе 
срезана), однако добавить к нему линии новой конфигурации 
нельзя. 

Дальнейшее улучшение рассматриваемого механизма защи¬ 
ты возможно путем присваивания имен отдельным элементам 
объекта. Если предоставлена возможность потенциальной адре¬ 
сации к объекту, являющемуся совокупностью отдельных («раз¬ 
личных») элементов (например, объект — это массив или набор 
переменных), то естественно предположить осуществимой по¬ 
тенциальную адресацию к элементам. Например, если процесс 
А имеет потенциальный адрес к объекту X, представляющему 
собой массив, то этот процесс может располагать средствами 
создания потенциального адреса элемента X (I); создав такой 
адрес, он может передать его процессу В. В результате про¬ 
цесс В получает доступ к определенному элементу объекта, но 
не ко всем другим элементам последнего. На практике процесс 
В может даже и не знать, что потенциальный адрес, которым 
он располагает, является элементом массива. 

Подобное применение потенциальной адресации позволяет 
достичь высокого уровня детальности расчленения совместно 
используемой информации и ее защиты от несанкционирован¬ 
ного доступа. Таким образом, потенциальный адрес можно счи¬ 
тать состоящим из трех компонентов: индикатора права на до¬ 
ступ, имени объекта и указателя элемента внутри объекта. 
В этом случае адрес можно определить как системное имя, за¬ 
щищенное от несанкционированного доступа и предоставляю¬ 
щее право на доступ к объекту или элементу внутри объекта. 

Принцип потенциальной адресации был сформулирован еще 
в 1966 г. *[16], однако пока не оказал значительного влияния 
на архитектуру вычислительных машин. Он широко обсуждал¬ 
ся при анализе операционных систем [10, 17—20] и был реали¬ 
зован программными средствами в экспериментальных опера¬ 
ционных системах, таких, как CAL [21] и Hydra [22]. Разно¬ 
видность потенциальной адресации нашла свое воплощение в 
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архитектуре вычислительной системы Plessey 250 [23], Систе¬ 
мы 38 фирмы IBM [24], микропроцессора іАРХ 432 фирмы In¬ 
tel [57], экспериментальной машины САР [25, 26], системы 
SWARD фирмы IBM і[27, 28, 58], а также в ряде других проек¬ 
тов [12, 29, 30]. Опубликовано несколько интересных статей, 
где дан обобщенный анализ потенциальной адресации [31—35]. 


ПОТЕНЦИАЛЬНАЯ АДРЕСАЦИЯ 
в АРХИТЕКТУРЕ ЭВМ SWARD 

Принцип потенциальной адресации широко используется в ар¬ 
хитектуре машины SWARD (см. часть V), поэтому данная его 
реализация может служить не только иллюстрацией, но и ос¬ 
новой для обсуждения ряда проблем, возникающих в случае 
применения такой адресации. 

Пользуясь ранее введенной терминологией, можно сказать, 
что упомянутая архитектура включает в свой состав объекты 

ПооГІ Потенциальный адрес I Рис. 4 - 10 Ячейка указателя 
L ^- J - —ft ---1 машины SWARD. 

пяти типов. Эти объекты — абстрактные понятия, поскольку их 
практическая реализация архитектурой не определяется; объек¬ 
ты определены лишь настолько, насколько это необходимо для 
описания операций, применимых к ним. Объекты четырех ти¬ 
пов — модули, порты, память данных и процесс-машины — со¬ 
здаются и уничтожаются программами явным образом; объек¬ 
ты пятого типа — записи активации — создаются и уничтожа¬ 
ются средствами управления подпрограмм неявным путем. 

Одна из разновидностей теговых ячеек этой архитектуры 
получила название указатель (рис. 4.10). Содержимое ячейки 
«указатель» — это потенциальный адрес или данные «неопреде¬ 
ленного» значения. Назначение отдельных битов потенциально¬ 
го адреса архитектурой не определяется; однако потенциальный 
адрес включает в себя четыре индикатора доступа и логический 
адрес объекта или элемента внутри объекта. Индикаторы до¬ 
ступа имеют следующие названия: чтение, запись, уничтожение 
и копирование. Первые три индикатора являются потенциаль¬ 
ными ограничителями типов операций, которые могут выпол¬ 
няться над элементами, адресуемыми с помощью потенциаль¬ 
ных адресов; четвертый индикатор сам «обслуживает» потен¬ 
циальный адрес. Если воспользоваться для сравнения какой-ли¬ 
бо аналогией реального мира, то можно рассмотреть, например, 
ситуацию, когда некое лицо А желает дать ключ лицу В и в то 
же время хочет предотвратить возможное изготовление послед¬ 
ним дубликата этого ключа (который мог бы попасть в руки 
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третьего лица). Возможным решением является гравировка на 
ключе для лица текста «не дублировать», т. е. указания, кото¬ 
рое соблюдают все изготовители дубликатов ключей. Следова¬ 
тельно, отсутствие разрешения на дублирование запрещает вла¬ 
дельцу потенциального адреса копировать потенциальный адрес 
в другой ячейке указателя. 

Для рассматриваемой архитектуры действительно следую¬ 
щее правило: при создании объекта формируется потенциаль¬ 
ный адрес, содержащий право на доступ всех видов: чтение, за¬ 
пись, уничтожение, копирование. В то же время предоставляет¬ 
ся команда, позволяющая лишить потенциальный адрес прав на 
некоторые (но не все) виды доступа. 

Чтобы не нарушать общности принципов программирования, 
ячейками «указатель» можно пользоваться так же, как адреса¬ 
ми в традиционных вычислительных системах (принимая во 
внимание, что над потенциальными адресами выполнение ариф¬ 
метических операций недопустимо). Ячейки «указатель» рас¬ 
сматриваются как ячейки определенного типа, отличного от 
других типов. В программе с указателями можно обращаться 
как с переменными: они могут существовать в пределах дейст¬ 
вия структуры данных пользователя и передаваться как факти¬ 
ческие параметры. Возвращаясь к рассмотренной выше анало¬ 
гии, можно сказать, что имеется возможность хранить ключи 
или связку ключей и другие «ценности» в запертых сундуках. 
Как уже было отмечено, механизм защиты потенциальных ад¬ 
ресов в нетеговой запоминающей среде обычно предполагает 
возможность их размещения только в специально отведенных 
для этой цели объектах (списках потенциальных адресов). 
Именно это имеет место в вычислительной системе САР Кемб¬ 
риджского университета, разработчики которой пришли к выво¬ 
ду о том, что использование отдельных списков потенциальных 
адресов (не размещаемых в упомянутых выше объектах) явля¬ 
ется недостатком системы :[26]. 

Выше упоминалось, что при описании архитектуры системы 
назначение отдельных битов потенциальных адресов (рис. 4.10) 
архитектурой системы не указывается (программа все равно 
их никогда непосредственно не «видит», а отсутствие предопре¬ 
деленного архитектурой назначения этих битов предоставляет 
свободу действий при практической реализации системы). Для 
знакомства с воплощением на практике подобной архитектуры 
полезно рассмотреть конкретный вариант использования таких 
84 бит. Например, 4 бит содержат директивную информацию, 
80 бит попользуются для описания уникального имени объекта 
(называемого SON — system object name — имя объекта си¬ 
стемы). Если потенциальный адрес предназначен для обраще¬ 
ния к элементу внутри объекта, то 24 бит используются как 



НАБОР СРЕДСТВ ДЛЯ СОВЕРШЕНСТВОВАНИЯ АРХИТЕКТУРЫ СИСТЕМЫ Ц7 


смещение тега элемента относительно начала объекта и еще 24 
бит —в качестве смещения содержимого элемента или его зна¬ 
чения. (Необходимость в двух смещениях объясняется тем, что 
данные элемента и его тег не обязательно размещаются в смеж¬ 
ных областях памяти, являясь, например, элементом массива.) 
Оставшиеся неописанными два последних бита играют роль 
специальных индикаторов. Если максимальный размер физиче¬ 
ски реализуемого адресного пространства равен 2 54 , то в нем 
может размещаться не более 2 30 объектов при условии, что раз¬ 
мер каждого из них не превышает 2 24 . 

Каждому объекту необходимо присвоить свое, присущее 
только ему имя, чтобы предотвратить программу от создания 
объекта, записи на хранение его потенциального адреса, унич¬ 
тожения объекта и возможного злоумышленного использования 
его потенциального адреса в дальнейшем для обращения к объ¬ 
екту, которому присвоено имя ранее существовавшего объекта. 
Очевидно, что отведенные 30 бит не являются неисчерпаемым 
источником уникальных имен, однако на практике этого оказы¬ 
вается достаточно по следующим двум причинам. Во-первых, 
при скорости создания объектов, равной 10 объект/с (записям 
активации, хотя и считающимся объектами, имя обычно не 
присваивается), упомянутый источник не может быть израсхо¬ 
дован машиной по крайней мере в течение 3,5 лет. Во-вторых, 
даже если прибегать к присваиванию уже использованных 
имен, вероятность нарушения защиты доступа мала, поскольку 
речь идет об архитектуре машины с теговой памятью (см. 
часть V). 

Получив возможность использования потенциального адре¬ 
са, машина должна обладать способностью переводить имя объ¬ 
екта в его местоположение в физически реализуемой памяти. 
Это осуществляется посредством карты взаимосвязи имен объ¬ 
ектов системы и физического местоположения этих объектов. 
Потенциальные адреса — это только некоторая форма адресов 
взаимосвязи объектов; использование этих адресов для обра¬ 
щения к отдельным элементам в пределах данного объекта не 
является обязательным. Ранее, при описании средств управле¬ 
ния подпрограммами и организации санкционированного досту¬ 
па с использованием доменов, указывалось, что программа для 
машины SWARD разделяется на модули, каждый из которых 
располагает своим собственным адресным пространством, одна 
часть которого расположена в самом модуле, а другая — в те¬ 
кущей записи активации. Для доступа к своим собственным 
операндам в этом адресном пространстве команды не пользу¬ 
ются потенциальными адресами; последние нужны только для 
обращения к внешнему адресному пространству. Например, 
если необходим доступ к массиву, который определен как не- 
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зависимый объект памяти данных, команда будет обращаться 
к ячейке «косвенный доступ к данным» в своем адресном про¬ 
странстве, которое содержит соответствующую ячейку «указа¬ 
тель» с потенциальным адресом объекта «массив». Этот меха¬ 
низм подобен механизму функционирования базированных пе¬ 
ременных в языке ПЛ/1 и переменных доступа в языке Ада. 

В дополнение к командам, создающим объекты, в рассматри¬ 
ваемой архитектуре имеется команда COMPUTE-CAPABILITY,, 
которая, получив адресуемый операнд, формирует его потен¬ 
циальный адрес. Если, например, имеется потенциальный адрес 
объекта «массив», то с помощью этой команды можно создать- 
потенциальный адрес для конкретного элемента массива. Ана¬ 
логично можно сформировать потенциальный адрес для локаль¬ 
ной переменной. Еще раз отметим, что хотя записи активации — 
это объекты, при их создании не происходит автоматического- 
присвоения им имен; это делается с целью предотвращения ис¬ 
черпывания источника уникальных имен для объектов, посколь¬ 
ку записи активации создаются намного чаще, чем объекты- 
других типов. Запись активации нуждается в уникальном имени 
только в том случае, когда программа выполняет команду 
CREATE-CAPABILITY для локальной переменной. Следова¬ 
тельно, машина присваивает имя записи активации только при 
наличии и в момент выполнения указанной команды, присваи¬ 
вающей потенциальный адрес локальной переменной в записи 
активации. 

Как и следовало ожидать, введение потенциальной адреса¬ 
ции вызывает новые проблемы, большинство которых имеет 
прямые аналоги с моделью реального мира в виде запираемых 
сундуков и ключей к ним. Перейдем к рассмотрению этих про¬ 
блем и их решению в машине SWARD. Одна проблема связана 
с предотвращением нежелательного копирования потенциально¬ 
го адреса, а также его «злоумышленной» передачи процессом 
или подпрограммой «третьей стороне». Эта проблема уже ра¬ 
нее упоминалась и решается включением директивной инфор¬ 
мации о копировании в потенциальный адрес. 

Другая проблема может быть определена как глобальное 
удаление потенциального адреса или как проблема «нового зам¬ 
ка». После распределения потенциальных адресов объекта нет 
возможностей для пересмотра решения (т. е. отказа от введен¬ 
ных потенциальных адресов), за исключением уничтожения 
объекта и его повторного создания с новым уникальным име¬ 
нем. В аналогичной ситуации для модели реального мира речь 
идет о желании сделать непригодными все имеющиеся в упот¬ 
реблении ключи, поскольку, во-первых, владение сундуком пе¬ 
редано в другие руки, во-вторых, существуют подозрения, что 
один или несколько владельцев ключей пользуются содержи- 
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мым сундука недозволенным образом, и, в-третьих, имеет ме¬ 
сто неопределенность, связанная с отсутствием информации о 
том, как были распределены ключи. Решение проблемы физи¬ 
ческой модели состоит в смене замка. 

В машине SWARD для той же цели используется команда 
CHANGE-LOGICAL-ADDRESS. Получив потенциальный адрес 
объекта (с директивной информацией «Разрешено уничтожение 
объекта») в качестве операнда, эта команда заставляет ма¬ 
шину «забыть» текущее имя объекта, присвоить ему новое имя 
и вернуть адресату потенциальный адрес с новым именем. 
В дальнейшем все попытки обращения посредством потенциаль¬ 
ного адреса со старым именем объекта завершаются сообще¬ 
нием об ошибке в программе. 

Еще одна проблема, порождаемая механизмом потенциаль¬ 
ной адресации, может быть сформулирована как проблема се¬ 
лективного удаления потенциальных адресов. Например, внача¬ 
ле ключи были выданы 10 лицам, а позже принимается реше¬ 
ние лишить лицо D такого ключа. В данном случае физическая 
модель оказывается неудобной для объяснения аналогиями, 
возможное решение не носит характера прямого действия: вме¬ 
сто того чтобы вручить ключ от самого сундука, дают ключ ог 
другого сундука, содержащего ключ к первому сундуку. Лицо 
или группу лиц можно лишить прав пользования ключом путем 
уничтожения одного из сундуков, хранящих ключи, или посред¬ 
ством смены замка в таком сундуке. 

В машине SWARD эта проблема решена введением косвен¬ 
ных потенциальных адресов, которые являются не дополнитель¬ 
ным типом данных, а содержимым любой ячейки «указатель», 
порожденным командой COMPUTE-INDIRECT-CAPABILITY. 
Эта команда располагает двумя операндами, каждый из кото¬ 
рых должен быть ячейкой «указатель». Логический адрес второ¬ 
го операнда вычисляется и записывается в первый операнд, 
помечая его как косвенный потенциальный адрес. 

Программа, использующая средства обычной потенциаль¬ 
ной адресации, не может отличить косвенный потенциальный 
адрес от обычного адреса. Физически косвенный адрес явля¬ 
ется ссылкой на другую ячейку «указатель», но логически (по 
сути адресации) это ссылка на тот же указатель. Любое обра¬ 
щение посредством косвенного потенциального адреса имеет то 
же действие, которое имеет место при использовании прямой 
потенциальной адресации. Операции, которые могут быть вы¬ 
полнены над содержимым ячеек типа «указатель» (например, 
копирование их содержимого в другие подобные ячейки, отмена 
разрешения на доступ определенного вида), можно выполнять 
и над указателями, содержащими косвенные потенциальные 
адреса. 
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Косвенная потенциальная адресация находит несколько при¬ 
менений, одним из которых является защита от несанкциониро¬ 
ванного доступа посредством селективного удаления потенци¬ 
альных адресов. Пусть процесс А намеревается предоставить, 
процессу В доступ к объекту X, но при этом хочет сохранить 
за собой возможность в любое время отменить право на этот 
доступ. Предоставляя В косвенный потенциальный адрес ука¬ 
зателя (в адресном пространстве А), содержащего ссылку на 
X, А может модифицировать в любое время этот указатель,, 
лишив тем самым В доступа к X. 

Другой очевидной проблемой рассматриваемой модели ре¬ 
ального мира является ситуация «потери ключей ». В случае по¬ 
тенциальной адресации это означает потерю всех потенциаль¬ 
ных адресов данного объекта. Например, по завершении созда¬ 
ния объекта ошибочно выполняется запись в ячейку единствен¬ 
ного указателя объекта. Родственной проблемой можно считать и 
потерю необходимых прав на доступ к объекту. Предположим* 
что ни один из потенциальных адресов объекта не имеет разре¬ 
шения на уничтожение объекта, а это означает, что последний; 
навсегда оккупировал адресное пространство системы. 

Существуют по крайней мере две точки зрения на пути ре¬ 
шения подобной проблемы. В соответствии с одной из них, фор¬ 
мулируемой для системы Intel 432 (но не для системы SWARD) ,. 
объект, не имеющий к себе ссылок, рассматривается как под¬ 
лежащий уничтожению: при этом предполагается существова¬ 
ние в машине средств сбора «программного мусора», опознаю¬ 
щих и уничтожающих такие объекты. Разработчики архитек¬ 
туры SWARD не нашли решения, которое не было бы крайне 
неэффективным или не нарушало функционирования средств 
защиты архитектуры. Однако соблюдение требований, связан¬ 
ных с защитой системы,— не единственное препятствие на пу¬ 
ти удовлетворительного решения рассматриваемой проблемы. 
Единственным связующим звеном между «осведомленностью» 
машины об объектах и восприятием этих же объектов програм¬ 
мами являются имена объектов в потенциальных адресах. При 
исчезновении последних программы и машина теряют единст¬ 
венное средство связи. 

Используя некоторые возможности архитектуры машины, 
можно по крайней мере частично устранить затруднения, лежа¬ 
щие на пути решения описанной проблемы. Во-первых, коман¬ 
ды, создающие объекты, позволяют указывать, подлежит ли 
объект автоматическому уничтожению машиной по завершении 
процесса создания объектов. Это используется при решении 
проблем, связанных с излишней продолжительностью «времени 
жизни» в системе большого числа объектов, предположительно 
временных, но вовремя не уничтоженных вследствие аномаль- 
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ного завершения процесса. Во-вторых, программам, создаю¬ 
щим постоянные (долговременного пользования) объекты, реко¬ 
мендуется (но не вменяется в обязанность) хранить свои по¬ 
тенциальные адреса в справочниках операционной системы. 
В-третьих, практически реализованный прототип машины дан¬ 
ной архитектуры содержит средства сбора «программного му¬ 
сора», которые позволяют обслуживающему персоналу осуще¬ 
ствлять поиск, возврат или уничтожение потерянных объектов. 

Еще одна проблема, связанная с использованием потенци¬ 
альной адресации, может быть названа проблемой «определе¬ 
ния нужного ключа из числа возможных». В аналогичной моде¬ 
ли реального мира это эквивалентно отсутствию информации о 
признаках ключа в связке ключей или такого ключа, который 
найден на земле. Речь идет о ситуациях, в которых машина 
располагает полезной информацией, не предоставленной про¬ 
граммам. Применительно к машине SWARD указанное можно 
сформулировать следующим образом. 

1. В программе отсутствуют явно описываемые средства 
прочтения директивной информации, содержащейся в потенци¬ 
альном адресе (например, нет средств проверки, содержит ли 
конкретный потенциальный адрес разрешение на запись). 

2. По имеющемуся потенциальному адресу нельзя непосред¬ 
ственно определить тип соответствующего объекта или элемента 
этого объекта: является ли этот объект программным модулем, 
точкой входа в модуль, ячейкой памяти данных, портом или 
чем-либо другим. 

3. Машина располагает определенной информацией о состо¬ 
янии объектов, которая недоступна программам. Примерами 
такой информации, необходимой программе, являются ответы 
на следующие вопросы: подлежит ли данный объект автомати¬ 
ческому уничтожению по завершении процесса? Активен ли 
данный модуль? Имеются ли ждущие обслуживания элементы 
в очереди данного порта? 

Данная проблема решена включением в набор команд ма¬ 
шины команды DESCRIBE-CAPABILITY. Располагая указате¬ 
лем и массивом в качестве операндов, команда возвращает в 
заданный массив необходимую информацию об объекте, описы¬ 
ваемом потенциальным адресом, который содержится в ука¬ 
зателе. Такой информацией может являться, например, класс 
адресата потенциального адреса и тип доступа, которым распо¬ 
лагает адресат. Если потенциальный адрес обеспечивает обра¬ 
щение ко всему объекту, то команда передает информацию о 
его состоянии. Только часть подобной информации не зависит 
от типа объекта. Описываемая команда не передает информа¬ 
цию о содержимом объекта. Так, в случае объекта «данные» 
она не описывает ни тип ячеек, ни их содержимое. 
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ДОСТОИНСТВА ПОТЕНЦИАЛЬНОЙ АДРЕСАЦИИ 

Надежность защиты от несанкционированного доступа. Потен¬ 
циальная адресация является простым средством защиты ин¬ 
формации от несанкционированного доступа. При ее использо¬ 
вании исчезает необходимость в таких средствах защиты, как 
выделение состояний системы (например, состояния «суперви¬ 
зор») или введение ключей защиты областей памяти. Дирек¬ 
тивная информация в форме спецификации в потенциальном 
адресе обеспечивает несколько уровней доступа к объектам* 
т. е. возможности, часто отсутствующие в традиционных вычис¬ 
лительных системах. Будучи принципиально простым механиз¬ 
мом, потенциальная адресация обладает двумя важными свой¬ 
ствами: во-первых, предоставляет доступ только к тому адре¬ 
сату, к которому имеет место обращение, и, во-вторых, не 
допускает подделки и несанкционированного генерирования 
потенциальных адресов, а также модификации их значе¬ 
ний. 

Еще одно достоинство потенциальной адресации как средст¬ 
ва защиты выявляется в ситуациях, когда специально принима¬ 
ются меры к временной отмене действия этого средства, напри¬ 
мер всевозможными программными «трюками» пытаются за¬ 
ставить операционную систему предоставить программе поль¬ 
зователя состояние «супервизор». В подобных случаях тради¬ 
ционная система становится полностью незащищенной от не¬ 
санкционированного доступа. В системе с потенциальной адре¬ 
сацией это приводит к появлению неразрешенного к использо¬ 
ванию (в нормальной ситуации) потенциального адреса, в ре¬ 
зультате чего незащищенным окажется только тот объект, на 
который этот адрес ссылается, а не вся система. 

Более простое совместное использование данных и про¬ 
грамм. Пользуясь в простейшем случае моделью памяти как 
единственным набором объектов, потенциальная адресация по¬ 
зволяет отказаться от традиционного механизма совместного 
использования данных и программ [31]. Все, что нужно сделать 
для этого в данном случае, сводится к предоставлению другой 
программе потенциального адреса объекта, которым до сих 
пор пользовалась только данная программа. 

Расширенные возможности уточнения границ областей санк¬ 
ционированного доступа и совместного использования данных и 
программ. Потенциальная адресация позволяет устанавливать 
границы доменов защиты и объектов совместного использова¬ 
ния посредством терминов, информативных для программы, что 
делает эти границы более гибкими, чем в машинах традици¬ 
онной архитектуры. Например, программа А может вычислить 
потенциальный адрес для переменной X и передать его про- 
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грамме В, предоставляя только этой программе доступ к пере¬ 
менной X. 

Унификация средств архитектуры машины. Объединяя ча¬ 
сто разъединенные средства адресации и защиты от несанкцио¬ 
нированного доступа и устраняя необходимость в таких «поло¬ 
винчатых» решениях введением состояний «привилегированная 
команда», потенциальная адресация способствует достижению 
значительной унификации принципов и средств архитектуры ма¬ 
шины. Представление информации в виде объектов позволяет 
проектировать вычислительную систему, придерживаясь прин¬ 
ципа унификации межобъектных связей (т. е. можно отказать¬ 
ся от практики применения одного принципа при организации 
взаимосвязи программных модулей, другого принципа для уста¬ 
новления связи программы с данными и т. д.). 

Более совершенные средства обнаружения ошибок. Благода¬ 
ря использованию в потенциальных адресах уникальных имен 
объектов машина способна обнаруживать программную ошиб¬ 
ку, известную под названием повисшая ссылка. Такая ошибка 
возникает, когда «время жизни» адреса превосходит «время жиз¬ 
ни» объекта, на который этот адрес ссылается. Предположим, что 
выполняется следующий оператор языка ПЛ/1: P=ADDR(X);. 
Возможны ситуации, когда переменная X уже исчезла, а пере¬ 
менная Р еще сохраняется. Например, X — локальная перемен¬ 
ная в процедуре, а Р — возвращенный параметр, причем по за¬ 
вершении процедуры исчезновение X логично, или же X — ди¬ 
намически определяемая переменная, действие которой в даль¬ 
нейшем отменяется. В современных вычислительных системах 
Р — это просто адрес, при использовании которого для обра¬ 
щения к памяти после уничтожения X возникает непредсказуе¬ 
мый результат. В системе с потенциальной адресацией значе¬ 
ние Р — это потенциальный адрес, при попытке использования 
которого после уничтожения X регистрируется невозможность 
вычисления фактического адреса, а следовательно, происходит 
обнаружение ошибки. 

ОДНОУРОВНЕВАЯ ПАМЯТЬ 

При использовании современных вычислительных систем про¬ 
граммист сталкивается с отсутствием единообразия и непре¬ 
рывности в модели памяти. Машина не может «скрыть» от не¬ 
го различия, существующие в адресации памяти, ее функциони¬ 
ровании и сохранении данных. Так, данные в основной памяти 
адресуются одним способом (например, значениями адресов, 
образующими одномерную монотонно меняющуюся числовую 
последовательность), а данные на поверхности магнитного ди¬ 
ска — совершенно другим способом (совокупностью значений 
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номеров дисковода, дорожки, записи и значением линейного 
смещения от начала записи). Базовые операции, такие, как 
сложение, сравнение, пересылка или копирование, не опреде¬ 
лены вместе для всей модели памяти. Поэтому программист 
должен явным образом указывать пересылку данных в запоми¬ 
нающую среду того типа, для которого необходимая функция 
определена. Кроме того, программист должен помнить, что в 
основной памяти информация удерживается только до завер¬ 
шения процесса, в то время как во внешней памяти она содер¬ 
жится до тех пор, пока не будет уничтожена явным образом. 

Указанное выше требует от программиста (а им часто яв¬ 
ляется прикладной программист) понимания, что памяти маши¬ 
ны присуща отмеченная нерегулярность организации. На про¬ 
граммиста возлагается обязанность явным образом задавать 
необходимые перемещения данных между различными запоми¬ 
нающими средами (т. е. выполнять операции ввода и вывода) 
с целью получения рабочей среды с требуемыми характеристи¬ 
ками адресации памяти, ее функционирования и сохранения 
данных. Кроме того, поскольку объем основной памяти часто 
ограничен, программисту приходится прибегать к запоминаю¬ 
щим средам с другими принципами организации данных (на¬ 
пример, файловая структура), которые представляют опреде¬ 
ленные возможности для передачи данных между программа¬ 
ми. Отсюда можно сделать вывод, что наличие запоминающих 
сред с различной организацией данных вносит свой вклад в 
высокую стоимость программирования. 

Перечисленные выше свойства памяти традиционной маши¬ 
ны являются причиной увеличения разнообразия типов интер¬ 
фейса между программами, что препятствует достижению еди¬ 
нообразия и модульности структуры программного обеспечения. 
В настоящее время программа может получать входную инфор¬ 
мацию двумя путями: через список фактических параметров 
(т. е. в виде структурированных или неструктурированных дан¬ 
ных, расположенных в основной памяти) или посредством опе¬ 
раций ввода в виде данных внешней памяти (имеющей, напри¬ 
мер, файловую структуру). Поскольку различия между этими 
двумя путями ввода информации слишком велики и очевидны, 
они редко одновременно сочетаются в одной программе. Если 
программный модуль (программа) А написан с указанием вво¬ 
да данных через список фактических параметров, то такой мо¬ 
дуль может оказаться неудобным для использования в тех слу¬ 
чаях, когда обработке подлежит большое количество входных 
данных (объем которых может превышать емкость основной 
памяти) или когда желательно выполнение программного мо¬ 
дуля А независимо от других программных модулей. Аналогич¬ 
но, если программный модуль В написан с указанием операций 
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ввода данных как файла, этот модуль может оказаться неудоб¬ 
ным для использования в таких ситуациях, когда подлежащие 
обработке данные размещены в другом программном модуле 
или когда файловая структура этих данных отличается от при¬ 
емлемой для модуля В структуры данных способом представле¬ 
ния в запоминающей среде (как, например, файлы на магнит¬ 
ной ленте отличаются от файлов на магнитных дисках). 

Решением указанных проблем является использование в ар¬ 
хитектуре машины простого принципа одноуровневой памяти- 
(Определение «простой», справедливое применительно к разра¬ 
ботке архитектуры машины, не обязательно применимо к этому 1 
принципу при его воплощении в реальной машине.) Указанны» 
принцип предполагает унификацию всех разновидностей запо¬ 
минающей среды вычислительной системы таким образом, что¬ 
бы при формировании интерфейса машины с программным» 
средствами все разновидности физически реализуемых запо¬ 
минающих устройств были представлены одинаковыми средст¬ 
вами адресации, наборами выполняемых функций и характе¬ 
ристиками представления данных в памяти. Например, условно' 
изображенная на рис. 4.9 модель запоминающей среды может 
представлять в таком случае не только основную память, но и 1 
все одноуровневое запоминающее пространство. Функциональ¬ 
ные элементы традиционной памяти — файлы — становятся те¬ 
перь объектами (элементами одноуровневой памяти) и адресу¬ 
ются согласно общим правилам обращения к объектам. Есл» 
же теперь по соображениям экономии средств или достижения 
требуемого быстродействия вычислительная система имеет 
иерархическую структуру памяти в виде совокупности запоми¬ 
нающих устройств различных стоимости и быстродействия, то 
функция перемещения данных между запоминающими устрой¬ 
ствами различных уровней иерархии возлагается на машину,, 
а не на программиста. 

Одноуровневая память во многом схожа с виртуальной па¬ 
мятью, однако имеются и различия. Во-первых, виртуальная па¬ 
мять (в общепринятом понимании этого термина) не предпола¬ 
гает унификацию отдельных, составляющих ее запоминающих-, 
сред; как правило, она предназначена просто для расширения 
тех функциональных возможностей системы, которые обычно- 
ограничены основной памятью. С этой точки зрения принцип 
одноуровневой памяти можно рассматривать как распростране¬ 
ние принципа виртуальной памяти на все запоминающее про¬ 
странство системы. Малопригодную для этих целей линейную- 
модель такого пространства желательно заменить описанной; 
выше моделью в виде набора объектов с потенциальными адре¬ 
сами (рис. 4.9). Во-вторых, при работе с виртуальной памятью- 
обычно с завершением выполнения программы «исчезает» и об- 
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служивающий ее набор запоминающих сред; то же самое про¬ 
исходит при выключении питания системы. Совсем другая кар¬ 
тина возникает при использовании одноуровневой памяти. На¬ 
пример, если желательно сохранить до следующего дня дан¬ 
ные программы, расположенные в объекте «массив», то нет не¬ 
обходимости создавать временный файл для их хранения; мас¬ 
сив просто удерживается в памяти. Отметим, что этот же прин¬ 
цип применим и к объекту «программа». Все зависит только 
ют того, как для такой ситуации разработчик архитектуры систе¬ 
мы определил понятие «загрузка программы». Например, ста¬ 
тические или собственные переменные могут сохранять свои 
значения между отдельными шагами выполнения программы. 
Это предоставляет не только простой механизм запоминания 
данных на время перехода от одного шага выполнения к дру¬ 
гому, но и вызывает необходимость пересмотра определения не¬ 
которых принципов, лежащих в основе языков программиро¬ 
вания. 

ДОСТОИНСТВА ОДНОУРОВНЕВОЙ ПАМЯТИ 

Сравнительно низкая стоимость программного обеспечения. 
Значительная часть средств, расходуемых на разработку про¬ 
граммы, затрачивается на решение сложных проблем ввода-вы¬ 
вода и (или) управление взаимодействием запоминающих сред 
разных уровней иерархии памяти. Последняя функция выпол¬ 
няется программистом с помощью программных средств. Одно¬ 
уровневая память не избавляет программиста от всех проблем 
ввода-вывода в программе, например организации ввода-выво¬ 
да для дисплеев и аналого-цифровых преобразователей, выво¬ 
да для печатающего устройства. Однако, если говорить о языке 
программирования, то использование одноуровневой памяти 
позволяет изъять из программ и языков много сложных конст¬ 
рукций, связанных с организацией ввода-вывода. Например, 
вместо явной записи в программе таких операций над файлами, 
как READ, WRITE, GET и PUT, достаточно определение фай¬ 
ла как массива или вектора, что предполагает в нужный мо¬ 
мент выполнение указанных операций. Кроме того, одноуров¬ 
невая память способствует достижению более совершенной мо¬ 
дульности программы благодаря единообразию формы всех за¬ 
поминающих сред, между которыми программа осуществляет 
пересылку данных. 

Может показаться, что все упомянутые достоинства одно¬ 
уровневой памяти достигаются при использовании в современ¬ 
ных вычислительных системах разработанных в последнее вре¬ 
мя пакетов управления базами данных. Однако это справедли¬ 
во лишь отчасти. Во-первых, об этом можно говорить примени- 
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тельно лишь к большим системам, обладающим такими пакета¬ 
ми, и только в случае использования последних. В меньших по 
размеру системах (на базе мини-ЭВМ или микропроцессоров) 
такие пакеты, как правило, отсутствуют. Во-вторых, наличие 
пакетов не избавляет программиста полностью от проблем ор¬ 
ганизации ввода-вывода: в программе осуществляется описание 
интерфейса записи данных в базу и копирования их оттуда. 
В-третьих, в настоящее время базы данных не охватывают 
файлы всех типов; они ориентированы на детально структури¬ 
рованные совокупности данных с относительно неизменной (ста¬ 
тичной) формой структуры и оказываются весьма неэффектив¬ 
ными при работе с небольшими динамическими наборами дан¬ 
ных или с неструктурированными данными. 

Независимость принципов организации памяти от реализу¬ 
ющей ее технологической базы. Очевидной характеристикой од¬ 
ноуровневой памяти является то, что конкретные запоминаю¬ 
щие устройства, реализующие эту память, и иерархия их взаи¬ 
моотношений скрыты за интерфейсом машины. Благодаря это¬ 
му программы легче «переносить» с одной системы на другую; 
они становятся менее зависимыми от конкретной конфигурации 
вычислительной системы. При этом разработчик машины сво¬ 
боден в выборе (или изменении) иерархии взаимосвязей запоми¬ 
нающих устройств, скрытых от программ интерфейсом маши¬ 
ны. Поскольку в настоящее время технология производства за¬ 
поминающих устройств быстро меняется, последнее из перечис¬ 
ленных выше обстоятельств представляется наиболее важным. 
Хотя общая тенденция технологии производства запоминающих 
устройств различных типов такова, что стоимость их падает, а 
быстродействие растет, соотношение между этими показателя¬ 
ми не сохраняется постоянным; кроме того, все время появля¬ 
ются запоминающие устройства с новыми характеристиками. 

В настоящее время проектировщику вычислительной систе¬ 
мы приходится принимать во внимание ряд факторов. Во-пер¬ 
вых, следует учитывать уменьшение разницы в стоимости маг¬ 
нитной запоминающей среды (например, памяти на магнитных 
дисках) и полупроводниковой. Во-вторых, имеет значение сход¬ 
ство по многим параметрам памяти на магнитных доменах 
(в виде сдвигающих регистров) и вращающихся магнитных ди¬ 
сках при наличии у памяти первого типа таких дополнительных 
свойств, как способность прекращать и возобновлять пересылку 
данных одновременно с изменением состояния механизма чте¬ 
ния-записи. Кроме того, существенно наличие высокоскорост¬ 
ных маломощных и дешевых полупроводниковых запоминаю¬ 
щих устройств произвольного доступа и энергонезависимых 
полупроводниковых запоминающих устройств произвольного* 
доступа. 
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Унификация средств архитектуры машины. Принцип одно¬ 
уровневой памяти не только позволяет программам «рассматри¬ 
вать» различные запоминающие среды как память одного ти¬ 
па — единой формы представления данных, но и распространя¬ 
ет такой подход к описанию возможностей всей системы (а не 
только в контексте с описанием функционирования основной 
памяти). Например, если в архитектуре системы используется 
принцип, именуемый «теговая память», он распространяется на 
всю иерархию запоминающих сред. Атрибут «теговый» приме¬ 
ним теперь и к совокупностям данных, которые ранее опреде¬ 
лялись как файлы. 

Глобальная оптимизация. В традиционных системах каждая 
программа, выполняющая операции ввода-вывода, управляет 
иерархией запоминающих устройств системы в соответствии со 
своими собственными критериями. Более того, как правило, 
процессор осуществляет независимое управление кэш-памятью, 
а операционная система — процессом «перелистывания» стра¬ 
ниц памяти. Весьма вероятно, что с позиций эффективности 
функционирования системы в целом эти локальные и независи¬ 
мые друг от друга операции далеки от оптимальных. Такие дей¬ 
ствия, как двойное буферирование, возможно совершенные для 
локальной оптимизации, могут оказаться весьма далекими от 
оптимальных в глобальном смысле этого определения. Вот по¬ 
чему «сокрытие» иерархии запоминающих сред от программ и 
управление ею единым механизмом может способствовать оп¬ 
тимизации этого процесса и работ системы в целом. Как и 
прежде, имея этот механизм за «фасадом» машинного интер¬ 
фейса, разработчик вычислительной системы располагает боль¬ 
шей свободой в выборе средств ее реализации, например ис¬ 
пользуя средства параллельного выполнения вычислений. 


ПРОБЛЕМЫ, ВОЗНИКАЮЩИЕ ПРИ ИСПОЛЬЗОВАНИИ 
ПРИНЦИПА одноуровневой памяти 

Реализуя практически принцип одноуровневой памяти, разра¬ 
ботчик вычислительной системы сталкивается с некоторыми но¬ 
выми проблемами. Время покажет, разрешимы они или их сле¬ 
дует отнести к недостаткам, присущим одноуровневой памяти. 

Реализация иерархии запоминающих устройств. Принцип од¬ 
ноуровневой памяти предполагает наличие иерархии запомина¬ 
ющих устройств, содержащих все данные и программы систе¬ 
мы. Эта иерархия, возможно, состоит из многих уровней запо¬ 
минающих сред с различными значениями таких параметров, 
как стоимость и быстродействие. К настоящему времени опыт 
.построения упомянутых иерархий еще мал (кэш-память, память 
произвольного доступа, память на магнитных дисках со стра- 
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ничной организацией) [36]. Необходимо проведение значитель¬ 
ных исследований с целью определения числа уровней иерар¬ 
хии, стратегии перемещения данных, размера единовременно 
пересылаемой информации (объект целиком, часть объекта, 
страница фиксированного размера), стратегии «сквозной запи¬ 
си» (т. е. выяснение, необходимо ли отражение выполнения опе¬ 
раций чтения в постоянной области объекта), требований к 
энергонезависимости памяти и рекомендаций по организации 
мультипроцессорной работы или работы с распределенными 
процессорами. 

Сохранение чистоты принципа одноуровневой памяти. Хотя, 
согласно изложенному выше, «сокрытие» от программ всех ха¬ 
рактеристик иерархии запоминающих сред (и даже самого 
факта существования такой иерархии) желательно, остаются 
спорными вопросы о практичности такого решения во всех си¬ 
туациях и необходимости предоставления определенным про¬ 
граммам средств осуществления локальной оптимизации. Речь 
идет о средствах, которые могли бы предложить, рекомендовать 
или директивно приказать программе следующее: перемещать 
сквозь иерархию запоминающих сред набор объектов, связан¬ 
ных «логикой» решаемой задачи; удерживать определенный 
объект в течение указанного периода времени в запоминающей 
среде наивысшего уровня иерархии; перемещать сквозь иерар¬ 
хию объекты (например, в таких ситуациях, как следующая: 
«я готов начать использование этого объекта»). Остается нере¬ 
шенным вопрос об определении того, какие именно средства до¬ 
статочны для поставленной цели и как представить их в архи¬ 
тектуре, соблюдая при этом требование максимально возмож¬ 
ной независимости принципов действия этих средств от путей 
их реализации. 

Восстановление памяти. Предполагая неизбежными наруше¬ 
ния в работе запоминающих устройств (например, повреждение 
головок записи и считывания, разрушение оксидного покрытия, 
искажение записи излучением альфа-частиц), естественно пред¬ 
положить, что применение принципа одноуровневой памяти, 
скрывающего от программ пользователя наличие иерархии за¬ 
поминающих сред и не позволяющего анализировать их струк¬ 
туру, должно затруднить процесс восстановления памяти. Это 
предположение основано на том, что процесс восстановления 
памяти существующих вычислительных систем требует привле¬ 
чения умственных способностей человека, т. е. анализа им кар¬ 
тины размещения информации в реальных, физических реали¬ 
зованных областях памяти (например, может появиться необ¬ 
ходимость выяснить, какие файлы находятся на тех или иных 
дорожках диска) и анализа содержания этой информации (так, 
может возникнуть потребность найти избыточные данные или 
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.определить способ реконструкции утерянных данных). Возмож¬ 
ным решением рассматриваемой проблемы является примене¬ 
ние самоопределяемых единиц пересылаемой информации (та¬ 
ких, как сегмент, страница), позволяющих их восстановление 
даже при разрушении системного справочника или нарушении 
в работе иерархии запоминающих сред, и создание служебного 
интерфейса для общения человека-оператора с памятью си¬ 
стемы. 

Транспортабельность объектов. Вычислительная система с 
одноуровневой памятью является замкнутой, т. е. ее объекты 
нельзя перенести в другие системы (объекты не обладают свой¬ 
ством транспортабельности). Поэтому задача переноса объекта 
из системы А в одноуровневую память системы В нуждается в 
специальном рассмотрении. Пользуясь средствами современной 
вычислительной техники, объект можно поместить в специаль¬ 
ный пакет дисков. Однако при использовании одноуровневой 
памяти местоположение объекта неизвестно; он может быть 
размещен даже по частям в различных запоминающих устрой¬ 
ствах. 

В случае применения потенциальной адресации также воз¬ 
никают проблемы транспортабельности объектов. Потенциаль¬ 
ный адрес объекта в одной системе теряет всякий смысл при 
переносе объекта в другую систему. 

Организация ввода-вывода устройств без памяти. Хотя при¬ 
менение одноуровневой памяти и позволяет отказаться от тра¬ 
диционных принципов организации ввода-вывода файлов, мо¬ 
дель такой памяти непригодна для описания ввода-вывода в 
устройствах без памяти и устройствах или запоминающих сре¬ 
дах, для которых не может использоваться произвольный или 
прямой доступ к памяти. Примерами устройств ввода-вывода 
без памяти являются экраны электронно-лучевых трубок, кла¬ 
вишные панели, устройства чтения перфокарт, устройства печа¬ 
ти, линии связи. Вообще говоря, и для них можно найти адек¬ 
ватное представление в модели памяти. В частности, в некото¬ 
рых микропроцессорных системах получил распространение 
принцип организации ввода-вывода по аналогии с обращением 
к памяти. Однако такое представление не является непосредст¬ 
венным и может служить источником дополнительных неопре¬ 
деленностей при функционировании системы. Например, такая 
запоминающая среда, как магнитная лента, непригодна для 
использования в качестве составной части одноуровневой па¬ 
мяти, поскольку для нее необходимы методы последовательно¬ 
го доступа. Следовательно, одноуровневая память не всегда 
позволяет отказаться от использования в архитектуре машины 
принципа ввода-вывода. 
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ОДНОУРОВНЕВАЯ ПАМЯТЬ 
В СИСТЕМЕ 38 ФИРМЫ IBM 

Поскольку Система 38 фирмы IBM [60], по всей видимости, 
является первой промышленно выпускаемой вычислительной си* 
стемой, в которой реализован принцип одноуровневой памяти, 
применение на практике этого принципа рассмотрим на приме¬ 
ре данной системы. Однако прежде всего следует ознакомиться 
со структурой этой неортодоксальной вычислительной системы. 
Современные варианты построения Системы 38 имеют двух- 



Рис. 4.11. Двухуровневая архитектура Системы 38. 


уровневую архитектуру (рис. 4.11). Архитектура внешнего уров¬ 
ня — так называемая МІ-архитектура — является доступной 
для программиста частью архитектуры этой вычислительной 
системы. На указанном уровне осуществляется компилирование 
программ. Однако этот уровень нельзя назвать интерпретиру¬ 
ющим. Когда программы загружены, средства внутреннего про¬ 
граммного обеспечения транслируют их на внутренний, более 
низкий, интерпретирующий уровень, именуемый ІМРІ-архитек- 
турой, ниже которого располагается машина с микропрограмм¬ 
ным управлением. Архитектура этого уровня программисту не¬ 
посредственно недоступна, благодаря чему изготовители Си¬ 
стемы 38 имеют возможность модифицировать ІМРІ-архитек- 
туру при создании последующих вариантов построения систе¬ 
мы. Хотя МІ-интерфейс (рис. 4.11) и не является интерпрети¬ 
рующим, внутреннее программное обеспечение создает у про¬ 
граммиста такую иллюзию (т. е. программные ошибки и ин¬ 
формация о состоянии системы сообщаются в терминах МІ-ин- 
терфейса). 

Отметим, что необычная структура данной вычислительной 
системы затрудняет определение ее архитектуры. Строго гово¬ 
ря, ІМРІ-интерфейс осображает архитектуру аппаратных 
средств машины, а МІ-интерфейс — программное обеспечение. 
Однако, поскольку для пользователя доступен только МІ-интер¬ 
фейс и на данном уровне передают результаты своей работы 
компиляторы, а также в связи с тем, что система создает ил- 
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люзию выполнения программ именно на этом уровне, можно 
считать, что МІ-интерфейс определяет архитектуру системы. 

Модель памяти МІ-интерфейса подобна той, которая пред¬ 
ставлена на рис. 4.9. Это — ориентированная на объекты мо¬ 
дель, использующая потенциальную адресацию и представляю¬ 
щая собой одноуровневую память. 

Одноуровневый принцип хранения информации в МІ-интер- 
фейсе базируется на следующих положениях. 

1. Имеются «суперобъекты», называемые объектами типа 
«группа доступа»; каждый объект этого типа может включать 
в себя один или несколько объектов других типов. Эти объек¬ 
ты используются для управления перемещением данных между 
адресатами иерархии запоминающих устройств. В объект «груп¬ 
па доступа» можно поместить объекты, к которым будет осу¬ 
ществляться одновременное обращение (например, объекты, 
совокупность которых образует определенную программу). 

В результате этого достигается следующий эффект: при обра¬ 
щении к одному объекту группы доступа другие ее объекты ис¬ 
пытывают тенденцию быть перемещенными в то же самое время 
в более быстродействующее запоминающее устройство. 

2. Явно задаваемая команда SET-ACCESS-STATE, которой 
располагает система, позволяет программе запрашивать пере¬ 
мещение объекта в основную память и удаление его из этой 
памяти. Такое перемещение объекта может быть определено 
как синхронное (выполнение команд вычислительного процесса 
не продолжается до тех пор, пока не будет удовлетворен за¬ 
прос) или асинхронное. 

3. Наличие команды ENSURE-OBJECT дает возможность 
программе заставлять систему сохранять текущую копию объ¬ 
екта в менее энергозависимой части иерархической памяти. Оп¬ 
ределенные изменения в объектах определенных типов понуж¬ 
дают систему автоматически выполнять функции этой команды. 
Система располагает также несколькими командами с необяза¬ 
тельными параметрами, задающими операцию принудительная 
запись. Эти команды обусловливают выполнение системой так 
называемой сквозной записи. Цель последней — сохранение ко¬ 
пии объекта в иерархической памяти. 

4. При формировании объекта создающая его программа 
может задавать «класс функционирования» этого объекта. Она 
может указывать объем информации объекта, подлежащий пе¬ 
редаче в основную память при обращении к этому объекту 
(обычно это секция размером 512 или 4096 байт). 

5. МІ-интерфейс содержит команды пересылки объектов на 
временное хранение в перемещаемую запоминающую среду 
(гибкие магнитные диски или магнитная лента), не являющую¬ 
ся составной частью одноуровневой памяти, а также команды 
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загрузки объектов из этой среды в одноуровневую память. 

6. Под МІ-интерфейсом расположены значительные по сво¬ 
им возможностям средства программного обеспечения, предна¬ 
значенные для восстановления объекта после аномального за¬ 
вершения работы системы. При повторном пуске системы созда¬ 
ется список восстановления, указывающий поврежденные объ¬ 
екты или те объекты, которые могли быть повреждены. Если 
объект определен как поврежденный, большинство операций с 
ним запрещено для сохранения целостности всей системы. 
МІ-интерфейс содержит также команду RECLAIM, при выпол¬ 
нении которой освобождается любое пространство памяти, не 
связанное с действующим объектом, и производится возврат 
списка «утерянных» объектов, т. е. объектов, не принадлежащих 
никому. 

7. МІ-интерфейс содержит отдельный набор функций по вы¬ 
полнению операций ввода-вывода для устройств без памяти. 

В ІМРІ-интерфейсе одноуровневая память реализуется с 
помощью принципов виртуальной и страничной организации па¬ 
мяти. ІМРІ-машина имеет традиционную архитектуру фон 
Неймана, хотя и с некоторыми нетрадиционными характеристи¬ 
ками. К последним следует отнести обширный диапазон адре¬ 
сов. Размер адреса равен 48 бит, что обеспечивает объем ли¬ 
нейной виртуальной памяти, равный 2 48 , или 281 -ІО 12 байт. 

Объем виртуальной памяти оказывается достаточно боль¬ 
шим для того, чтобы включить в систему все запоминающие 
устройства. Виртуальная память размером 2 48 байт с двухуров¬ 
невой иерархией запоминающих устройств (память произволь¬ 
ного доступа и накопители на магнитных дисках) позволяет со¬ 
здать одноуровневую запоминающую среду, в которой переме¬ 
щение данных осуществляется страницами фиксированного раз¬ 
мера (512 байт). Виртуальный адрес 48 бит воспринимается 
машиной как состоящий из двух частей: 39-битового адреса 
страницы и 9-битового смещения внутри этой страницы. Аппа¬ 
ратные средства обработки адреса преобразуют первые 39 бит 
в адрес кадра 512-байтовой страницы в основной памяти (или 
генерируют сигнал прерывания при отсутствии страницы в ос¬ 
новной памяти) и добавляют к нему 9-битовое смещение, фор¬ 
мируя таким образом адрес области основной памяти. Из-за 
большого размера адреса вместо традиционных линейных таб¬ 
лиц страниц используются так называемые хэш-таблицы 1) . 

Перемещение данных между отдельными устройствами двух¬ 
уровневой иерархии запоминающих устройств осуществляется 


1 Речь идет о таблицах адресации данных, положение элемента в кото¬ 
рых определяется преобразованием имени элемента данных в адрес фиксиро¬ 
ванной длины. — Прим. ред. 
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с помощью программных средств ІМРІ-архитектуры подобно 
тому, как выполняются операции над страницами в других си¬ 
стемах. Объекты располагаются в сегментах 2 48 -байтового вир¬ 
туального адресного пространства, использующего для неболь¬ 
ших объектов 64К-байтовые сегменты, а для больших объек¬ 
тов — 16М-байтовые. В состав программного обеспечения вхо¬ 
дит несколько справочников виртуальных адресов с соответст¬ 
вующими им адресами областей памяти на дисках. Для облег¬ 
чения процесса восстановления (например, в случае поврежде¬ 
ния указанных справочников) все страницы на магнитных ди¬ 
сках являются самоолределяемыми, поскольку содержат свой 
виртуальный адрес в качестве префикса. 

Потенциальные адреса одноуровневой памяти в МІ-интер- 
фейсе имеют размер, равный 16 байт. Шесть байт такого адре¬ 
са используются для записи виртуального адреса объекта, к ко¬ 
торому имеет место потенциальная адресация. 

Языками программирования Системы 38 являются РПР> и 
КОБОЛ. Использование принципа одноуровневой памяти не 
привело ни к каким изменениям этих языков. Следствием этого 
является то, что использование указанного принципа не имеет 
значения для прикладного программиста: прикладные програм¬ 
мы выполняют операции ввода-вывода так же, как это имело 
бы место в других системах. Достоинства одноуровневой памя¬ 
ти не являются средствами, непосредственно предоставляемы¬ 
ми пользователям системы, хотя именно благодаря им конст¬ 
рукторы фирмы IBM сумели достичь значительных успехов в 
разработке программного обеспечения рассматриваемой си¬ 
стемы. 


УПРАВЛЕНИЕ ПРОЦЕССОМ 

Как указано в гл. 2, существует большой семантический раз¬ 
рыв между современными операционными системами и архи¬ 
тектурой машин, обеспечивающих работу этих систем. Опера¬ 
ционные системы представляют собой совокупность больших, 
чрезвычайно сложных программ, проектирование и разработка 
которых часто является «узким местом» проекта новой вычис¬ 
лительной системы, причем операционная система часто пре¬ 
пятствует достижению требуемого быстродействия в современ¬ 
ных системах. 

Частичным решением этой проблемы является переложение 
некоторых традиционных функций операционной системы на 


Сокращение, соответствующее английской аббревиатуре RPG (Report 
Program Generator). — Прим, перев. 
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аппаратные средства. В остальных случаях необходимо опре¬ 
делять границу между тем, что можно вменить в обязанность 
машине, и тем, что необходимо сохранить как функции, реали¬ 
зуемые программными средствами. Первую категорию функций 
операционной системы можно назвать функциями, определяе¬ 
мыми «механизмами» системы, а вторую — функциями, опреде¬ 
ляемыми «политикой» выполнения заданий. Типичными функ¬ 
циями первой категории являются управление процессом, защита 
информации от несанкционированного доступа, управление па¬ 
мятью. Типичные функции второй категории — организация- 
выполнения заданий, оценка стоимости выполнения заданий на 
ЭВМ, идентификация заданий директивами пользователя. По¬ 
скольку функции второй категории меняются с изменением 
внешних условий работы системы (часто эти изменения дол¬ 
жен вносить системный программист) и базируются на возмож¬ 
ностях упомянутых «механизмов» системы, представляется це¬ 
лесообразным осуществлять реализацию указанных «механиз¬ 
мов» аппаратными средствами и избегать подобной реализации 
функций, определяемых «политикой» выполнения задания поль¬ 
зователей. 

Перечислим функции операционной системы, реализация ко¬ 
торых с помощью аппаратных средств представляется наиболее 
вероятной: 

1. Управление процессом: коммутация процессора (процес¬ 
соров) между процессами; создание и уничтожение процессов; 
синхронизация процессов; организация связи между процес¬ 
сами. 

2. Управление памятью: распределение пространства памя¬ 
ти; неявное перемещение информации между отдельными уст¬ 
ройствами иерархической памяти (например, пересылка стра¬ 
ниц); явное перемещение информации между ними (ввод-вы¬ 
вод файлов). 

3. Защита от несанкционированного доступа: защита про¬ 
грамм и данных друг от друга; передача средств защиты. 

Поскольку управление памятью было освещено при рассмот¬ 
рении средств функционирования подпрограмм и одноуровне¬ 
вой памяти, а защита от несанкционированного доступа — при 
анализе потенциальной адресации, в данном разделе главным 
образом рассматриваются вопросы управления процессом. 

Процесс, или задача, — это последовательное выполнение 
потока команд, т. е. выполнение нескольких команд без совме¬ 
щения во времени. Большинство современных операционных 
систем допускает совмещение во времени нескольких процес¬ 
сов. (Если в распоряжении системы находится только один про¬ 
цессор, то указанное совмещение является своего рода иллюзи¬ 
ей. создаваемой за счет разделения процессов на временные 
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Интервалы и перехода процессора от обслуживания некоторого 
интервала одного процесса к интервалу другого процесса.) 

Рассмотрим основные функции операционной системы по 
управлению процессами. 

Коммутация процессоров. Поскольку число процессов редко 
равно числу аппаратно реализованных процессоров и, как пра¬ 
вило, нуждающихся в обслуживании процессов больше, необ¬ 
ходим механизм распределения процессоров между процесса¬ 
ми. Вычислительная система обычно предоставляет средства 
для переключения процессора на обслуживание другого про¬ 
цесса в следующих трех случаях: 1) когда текущий процесс 
достигает точки, в которой выполнение должно быть приоста¬ 
новлено (т. е. должно наступить «состояние ожидания»), 
2) когда приостановленный процесс более высокого приоритета 
выходит из состояния ожидания или 3) когда текущий процесс 
выполняется в течение слишком долгого времени (прекращение 
непрерывного обслуживания такого процесса осуществляется 
для обеспечения «продвижения вперед» всех процессов или по 
крайней мере для создания видимости равного продвижения 
всех процессов). 

Механизму, переключающему процессор на другой процесс, 
необходимо знать, какому из других процессов отдать предпоч¬ 
тение. Подобные решения часто базируются на стратегии рас¬ 
пределения приоритетов (каждому процессу присваивается оп¬ 
ределенное значение приоритета: наивысший приоритет получа¬ 
ет процесс, которому отдается наибольшее предпочтение) или 
стратегии «предельного срока». Во втором случае каждому про¬ 
цессу назначается предельный срок его обслуживания процес¬ 
сором. Возврат к продолжению незавершенного процесса осу¬ 
ществляется согласно расписанию, при этом в памяти системы 
хранятся предельные сроки однократного обслуживания всех 
процессов. Поскольку указанные стратегии относятся к так на¬ 
зываемой «политике» выполнения заданий и часто подверга¬ 
ются модификации при настройке системы на конкретное при¬ 
менение, следует избегать реализации конкретной стратегии в 
архитектуре машины; однако в ней должны быть предусмотре¬ 
ны определенные механизмы, обеспечивающие воплощение этих 
стратегий программными средствами. 

Создание процесса. Существует немного практических ситуа¬ 
ций, в которых приемлемо использование вычислительной си¬ 
стемы с фиксированным набором процессов. Чаще всего воз¬ 
никает потребность в механизме, позволяющем создавать одни 
процессы и уничтожать другие, пересылать данные и (или) по¬ 
тенциальные адреса формируемым процессам. 

Управление одного процесса другим. Система должна рас¬ 
полагать средствами, позволяющими одному процессу управ- 
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лять протеканием другого процесса. Типичные средства такого 
рода получили название SUSPEND (прекращение выполнения 
другого процесса без его разрушения) и RESUME (разреше¬ 
ние продолжения выполнения приостановленного процесса'). 
Указанные средства оказываются полезными при реализации 
программными средствами стратегий обслуживания процессов 
по расписанию. 

Синхронизация и связь. Эти разновидности управления про¬ 
цессами рассматриваются вместе, поскольку иногда для их реа¬ 
лизации используется один и тот же механизм. Синхрониза¬ 
ция необходима, когда несколько процессов одновременно нуж¬ 
дается в том или ином ресурсе, допускающем только последо¬ 
вательное использование, т. е. использование в порядке очеред¬ 
ности. Средства межпроцессорной связи необходимы для пере¬ 
дачи информации (данных, синхросигналов и т. п.) от одного 
процесса к другому. Имеется обширная литература по операци¬ 
онным системам, в которой освещаются принципы построения 
соответствующих механизмов, таких, как семафоры, почтовые 
ящики, средства приема и передачи, критические секции, мони¬ 
торы, очереди и т. п. [37—43]. 

Управление ресурсами. Система нуждается также в средст¬ 
вах ограничения ресурсов (например, пространства памяти), 
которые могут использоваться процессом. 


УПРАВЛЕНИЕ ПРОЦЕССАМИ 
в АРХИТЕКТУРЕ МАШИНЫ SWARD 

Обратимся к архитектуре машины SWARD с целью рассмот¬ 
рения конкретного примера аппаратных средств «поддержки» 
принципов управления процессом. Ранее упоминалось, что для 
этой архитектуры допускается использование объектов пяти ти¬ 
пов, два из которых имеют прямое отношение к управлению 
процессами. 

Речь идет о следующих объектах: 

1) модуль набор ячеек данных, определяющих область 
(домен) санкционированного доступа, и последовательность 
машинных команд; последние могут представлять собой одну 
процедуру, набор процедур или процедуру с множеством точек 
входа; 

2) память данных — динамически выделяемая память для 
ячейки данных; 

3) запись активации — набор ячеек данных, представляю¬ 
щих ту часть домена адресации модуля, которая динамически 
выделяется при каждом переходе модуля в активное состояние 
(активация модуля); при переходе модуля в это состояние со¬ 
здается одна запись активации; 
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4) процесс-машина — объект, выполняющий параллельно с 
другими процесс-машинами один или несколько модулей; 

5) порт — объект, через который один процесс может по¬ 
слать значения данных в другой процесс. 

Процесс-машина представляет собой процессор, который вы¬ 
полняет последовательную программу. Степень взаимосвязи 
этого процессора с аппаратно реализуемыми процессорами оп¬ 
ределяется конкретным техническим решением проекта вычис¬ 
лительной системы. Эта взаимосвязь скрыта в архитектуре си¬ 
стемы, т. е. программы остаются в «неведении» относительно 
того, разделяют ли между собой несколько процесс-машин один 
реальный процессор или m процесс-машин — п реальных про¬ 
цессоров. Принципиально процесс-машина выполняет роль ис¬ 
полнителя команд, счетчика команд, стека записей активации 
и другой информации о состоянии системы, хотя ее архитекту¬ 
ра определяется только командами, которые могут обращаться 
к этой процесс-машине. 

Процессы создаются путем выполнения команды CREATE- 
PROCESS-MACHINE, схожей с командой CALL, но содержа¬ 
щей дополнительный операнд, в который осуществляется воз¬ 
врат адреса создаваемой процесс-машины. Иначе говоря, эта 
команда означает: «Начать выполнение указанного модуля с 
заданной точки входа как параллельного процесса и произве¬ 
сти возврат потенциального адреса созданной процесс-машине». 

Процесс-машины уничтожаются, во-первых, путем выполне¬ 
ния инвариантной к типу обрабатываемых данных команды 
DESTROY, в качестве операнда которой задается потенциаль¬ 
ный адрес данной процесс-машины; во-вторых, выполнением 
процесс-машиной команды RETURN при начальной активации 
этого процесса; в-третьих, если эта возможность указана не¬ 
обязательным параметром команды CREATE-PROCESS-MA- 
GHINE, при разрушении процесс-машины, выполняющей про¬ 
цесс, который создан этой процесс-машиной. Любая процесс- 
машина, располагающая потенциальным адресом другой про¬ 
цесс-машины, может задержать выполнение операций в послед¬ 
ней процесс-машине, возобновить их, изменить приоритет их 
выполнения или сформировать признак наличия ошибки посред¬ 
ством команды CONTROL-PROCESS-MACHINE. 

Две машинные команды, SEND и RECEIVE, а также объ¬ 
ект «порт» являются средствами коммуникации между несколь¬ 
кими процессами. Команда SEND определяется почти так же, 
как и команда CALL. Исключением является содержание пере¬ 
сылаемой информации и ее адресат: команда CALL передает 
управление и набор фактических параметров в точку входа ука¬ 
занного модуля, а команда SEND посылает набор значений па¬ 
раметров через указанный порт. Команда, RECEIVE пересыла- 
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ет набор значений из порта в группу указанных локальных 
ячеек. 

Команды SEND и RECEIVE выполняются синхронно. Когда, 
например, процесс-машина А выполняет команду, предписыва¬ 
ющую пересылку значений содержимого ячеек X и Y через 
порт К, выполнение процесса приостанавливается, если дру¬ 
гая процесс-машина не ожидает приема у этого порта. Готов¬ 
ность к приему может возникнуть у нее только как результат 
выполнения команды RECEIVE. Как только это происходит, 
возобновляется выполнение приостановленного процесса. Взаи¬ 
модействие этих команд подобно так называемому свиданию 
процессов (rendezvous) в языке Ада [44]. В результате вместо 
очереди сообщений (наборов значений переменных) у порта 
имеет место очередь процесс-машин. 

Описанный механизм функционирования интерфейса прие- 
мо-передачи служит также для выполнения проверки данных 
на соответствие типов. Это возможно благодаря тому, что в 
рассматриваемой архитектуре используется теговая память. 

Механизм приемо-передачи можно использовать и для за¬ 
щиты так называемой критической секции программы от одно¬ 
временного выполнения ее команд многопроцессорными маши¬ 
нами, хотя его использование для этой цели может оказаться 
неудобным и неэффективным. Однако в данной архитектуре 
реализован другой, чрезвычайно простой механизм синхрониза¬ 
ции, который базируется на принципе синхронизации последо¬ 
вательностей команд, лежащем в основе монитора — этого важ¬ 
ного элемента программного обеспечения вычислительных си¬ 
стем [37]. 

Монитор — это совокупность одной или нескольких проце¬ 
дур, использующих определенные ресурсы системы, например 
таблицу данных, буферный пул, устройство ввода-вывода. Мо¬ 
нитор имеет двойное назначение: во-первых, сокрытие струк¬ 
туры и физических характеристик ресурсов с целью улучшения 
структуры системы в целом; во-вторых, выполнение необходим 
мой синхронизации при пользовании ресурсами (только одному 
процессу в каждый момент времени разрешается выполнение 
всех или части машинных кодов, содержащихся в мониторе). 
Вместо того чтобы предоставлять всем программам непосредст¬ 
венный обзор ресурсов и необходимые средства синхронизации 
пользования ими, архитектура системы предполагает следу¬ 
ющее: для выполнения операции с ресурсами каждый процесс 
обращается к монитору. Отметим, что изучение одновременного 
обслуживания процессов средствами языка Ада, обеспечиваю¬ 
щего необходимые коммуникации между процессами, но не рас¬ 
полагающего мониторами, показывает необходимость обоих ме¬ 
ханизмов [59]. 
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■Поскольку в программе, принадлежащей более абстрактно¬ 
му описанию машины SWARD, чем ее архитектура, монитор 
представляется как объект «модуль», в архитектуре SWARD 
имеется простой механизм синхронизации, ориентированный на 
модули. Он определяется командами GUARD и UNGUARD, 
которые не имеют операндов. Когда процесс-машина выполняет 
содержащуюся в модуле команду GUARD, происходит одно из 
двух действий. Если модуль не находится в состоянии «охраня¬ 
ем» (guarded state), он переходит в это состояние, и выполне¬ 
ние продолжается со следующей команды. Если же модуль уже 
пребывает в указанном состоянии, выполнение действий про¬ 
цесс-машины приостанавливается на этой команде, и процесс- 
машина помещается в очередь на данный модуль в состоянии 
«охраняем». Выполнение команды UNGUARD заставляет мо¬ 
дуль выйти из состояния «охраняем», после чего выполнение 
продолжается со следующей команды. Если какая-нибудь про¬ 
цесс-машина находится в очереди на данный модуль в состоя¬ 
нии «охраняем», то первая из таких процесс-машин из очереди 
удаляется, а ее операции возобновляются. 

Принцип использования процесс-машин «ортогонален» всем 
другим принципам рассматриваемой архитектуры, таким, как 
адресация и распределение памяти. Этот принцип базируется 
на модели архитектуры, в распоряжении которой имеется не¬ 
ограниченное количество процессоров. Однако принцип одно¬ 
уровневой памяти предполагает использование пусть большого, 
но фиксированного числа запоминающих устройств. Следова¬ 
тельно, возникает потребность в механизме, ограничивающем 
объем памяти, который может быть запрошен процесс-машиной 
как для управления системой, так и для предотвращения созда¬ 
ния процессом объектов, «ускользающих» из-под его контроля. 
Работа такого механизма основывается на использовании двух 
количественных характеристик объема памяти (amount of me¬ 
mory) : AM и AM имеющейся в распоряжении памяти. 

Будучи атрибутом объекта, AM является в некотором смы¬ 
сле расплывчатой мерой памяти, занимаемой объектом. По¬ 
скольку объекты непосредственно программам не доступны («не 
видны») и в связи с этим могут менять свою форму при пере¬ 
ходе от одной реализации данной архитектуры к другой, AM не 
является мерой точного числа байтов или битов, занимаемых 
объектом. Это только некоторая грубая относительная оценка 
указанного параметра. Архитектура машины позволяет дать, 
например, следующие оценки: 

порт занимает приблизительно 0,005—0,01 AM; 

объект «память данных», предоставляющий массив двухсот 

10-символьных полей, занимает ~1 AM; 

объект «процесс-машица» занимает примерно 0,1—0,3 AM. 
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При задании характеристик архитектуры указывается, что 
программы не должны использовать в качестве точных значе¬ 
ний величины, измеряемые в AM. (Отметим, что при реализа¬ 
ции прототипа машины SWARD AM считается равным ІбКбит). 

Помимо того что процесс-машина сама занимает некоторую 
память размером AM, в ее распоряжении для создания объек¬ 
тов имеется еще некоторый объем свободной памяти, оценивае¬ 
мый характеристикой «АМ имеющейся в распоряжении памя¬ 
ти». Измеряемая в АМ память, необходимая для создания объ¬ 
екта, заимствуется из памяти, имеющейся в распоряжениии 
данной процесс-машины. Принято говорить, что «АМ создавае¬ 
мого объекта вычитается из АМ имеющейся в распоряжении 
памяти». Количество АМ имеющейся в распоряжении памяти, 
которое подлежит пересылке от создающей процесс-машины к 
создаваемой процесс-машине, задается в виде операнда коман¬ 
ды CREATE-PROCESS-MACHINE. Кроме того, имеется команда 
TRANSFER-AM, позволяющая одной процесс-машине (если 
она владеет необходимыми потенциальными адресами) переме¬ 
щать между двумя другими процесс-машинами АМ имеющейся 
в распоряжении памяти. 

При рассмотрении организации одноуровневой памяти отме¬ 
чалось, что для представления устройств ввода-вывода без па¬ 
мяти нужны специальные средства. В архитектуре SWARD для 
этих целей используются некоторые средства управления про¬ 
цессом. Принята следующая модель: устройства без памяти 
(терминалы, устройства печати и т. п.) представлены потенци¬ 
альными адресами, а для выполнения операций ввода-вывода 
используются команды SEND и RECEIVE. Терминал можно 
рассматривать как порт, а работающего за терминалом чело¬ 
века-оператора— как процесс. Такая модель имеет два досто¬ 
инства. Во-первых, она позволяет пользователю заменять про¬ 
цессы устройствами ввода-вывода и, наоборот, замещать эти 
устройства процессами без изменения программы. Во-вторых, 
благодаря синхронному режиму работы механизма приемо-пе- 
редачи устраняется потребность в использовании системы пре¬ 
рываний, что позволяет архитектуре машины придерживаться 
единообразного принципа асинхронной работы, реализуемого в 
виде процесс-машины. (Асинхронные операции устройств вво¬ 
да-вывода без памяти можно реализовать путем создания от¬ 
дельного процесса для их выполнения.) 

При попытке реализации той или иной функции системы 
средствами, на которых базируется архитектура системы, воз¬ 
никают проблемы функционирования и отладки соответствую¬ 
щих программ, для которых (и тем самым для людей, их созда¬ 
ющих) становится «невидимой» информация о состоянии си¬ 
стемы. В машине SWARD для решения этих проблем вводится 
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дополнительно несколько команд. В одной из них — команде 
DESCRIBE-CAPABILITY — в качестве операндов используют¬ 
ся ячейка указателя и массив. Эта команда заполняет массив 
информацией о задаваемом в указателе потенциальном адресе 
и объекте (или его составной части), к которому этот потенци¬ 
альный адрес относится. Информация о потенциальном адресе 
включает директивную информацию о так называемых правах 
доступа, которыми этот адрес «владеет». Информация об объ¬ 
екте зависит от типа последнего. Если, например, это — объ¬ 
ект «модуль», рассматриваемая команда дает следующую ин¬ 
формацию: 1) каков объем (в единицах, называемых AM) па¬ 
мяти, занимаемой объектом; 2) активен ли объект (т. е. имеет 
ли записи активации); 3) находится ли объект в состоянии «ох¬ 
раняем»; 4) подлежит ли модуль уничтожению явным образом 
при уничтожении создающей процесс-машины. Для объекта 
«порт» команда DESCRIBE-CAPABILITY указывает количество 
процесс-машин, стоящих в очереди к этому порту. Для объ¬ 
екта «процесс-машина» данная команда указывает в единицах 
AM объем памяти, предоставленный в распоряжение этому объ¬ 
екту, и состояние последнего: активен ли он, приостановле¬ 
но ли его выполнение, блокирован ли он модулем, находя¬ 
щимся в состоянии «охраняем», ожидает ли своей очереди у 
порта. 

Вторая команда DESCRIBE-PROCESS-STACK предназна¬ 
чена именно для процесс-машин. Располагая потенциальным 
адресом для процесс-машины, эта команда возвращает в опе¬ 
ранд, являющийся массивом, описание текущего стека актива¬ 
ции процесс-машины. Каждый элемент описывает активацию 
модуля, поскольку содержит потенциальный адрес модуля (по¬ 
тенциальный адрес не располагает директивной информацией с 
правом создания защиты от несанкционированного доступа) и 
индекс следующей команды, подлежащей выполнению. 

ДРУГИЕ ПРИМЕРЫ 

Помимо рассмотренного выше известны и другие предложения 
по коммутации процессов и их синхронизации средствами ма¬ 
шины [12, 45, 46]. Примером промышленно изготовляемых ма¬ 
шин такого типа являются ЭВМ фирмы Honeywell, серия 60, 
уровень 64 [47, 48]. Для того чтобы машина могла идентифи¬ 
цировать процессы, строится блок управления процессами и вы¬ 
полняется команда «Начало процесса». Коммутацию процессов 
осуществляет машина, используя блок управления процессами 
для записи в него на хранение информации о состоянии систе¬ 
мы. Для синхронизации процессов набор команд включает так 
называемый механизм типа семафор. 
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В микропроцессоре Intel 432 большая часть функций по уп¬ 
равлению процессами выполняется непосредственно кристаллом 
благодаря использованию того же принципа, что и в машине 
SWARD (разделение указанных функций на определяемые 
«механизмами» системы и определяемые «политикой» выполне¬ 
ния заданий), при этом определяется похожий набор объектов. 
Более подробно этот вопрос рассматривается в гл. 17. 

ДОСТОИНСТВА УПРАВЛЕНИЯ ПРОЦЕССАМИ 

Повышенное быстродействие системы. Возложение на машину 
функций создания процессов, их коммутации и синхронизации 
оказывает значительное влияние на скорость выполнения этих 
функций, что в свою очередь приводит к увеличению эффектив¬ 
ности выполнения программ и улучшению стиля программиро¬ 
вания. Многие специалисты признают, что использование одно¬ 
временно протекающих процессов является естественным и ра¬ 
циональным способом структурирования многих прикладных за¬ 
дач. Однако программисты часто избегают таких процессов, по¬ 
скольку при этом повышаются накладные расходы (за счет ча¬ 
стого создания и уничтожения процессов). Передача функций 
управления процессами машине помогает преодолеть этот не¬ 
желательный эффект путем снижения не только абсолютных, но 
и относительных величин накладных расходов по созданию про¬ 
цессов по сравнению с другими операциями, например операци¬ 
ей сложения. Так, в машине SWARD команда CREATE-PRO- 
CESS-MACHINE является заменителем функции команды 
CALL, но в аппаратно реализованном прототипе машины время 
ее выполнения только на 35% больше времени выполнения 
команды CALL. 

Расширенные возможности реализации системы. Как и при 
анализе эффекта использования других принципов организации 
вычислительной системы, рассмотренных в этой главе, вклю¬ 
чение управления процессами в состав функций аппаратных 
средств машины создает новые возможности для ее реализации. 
Для современных вычислительных систем с архитектурой низ¬ 
кого уровня организации основным средством повышения быст¬ 
родействия является конвейерная обработка. Однако широкое 
применение конвейерной обработки, хотя и обеспечивает высо¬ 
кую эффективность работы вычислительной системы, обходится 
дорого вследствие необходимости выявлять взаимозависимость 
команд и из-за сложности алгоритмов обработки прерываний в 
последовательном потоке команд (содержащем, например, ус¬ 
ловные переходы и прерывания). 

Введение в архитектуру системы таких простых средств уп¬ 
равления процессами, какие предусмотрены в машине SWARD, 
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предоставляет разработчику вычислительной системы дополни¬ 
тельные возможности. Например, конструктор может строить 
машину, на которой базируется архитектура системы, в виде 
набора простых процессоров неконвейерного типа. Каждый про¬ 
цессор после потери возможности продолжать действовать как 
конкретная процесс-машина ищет другую процесс-машину с 
целью «подражания» ей. Но поскольку коммутация процессов 
осуществляется за интерфейсом машины (т. е. на аппаратном 
уровне), указанное выше при желании может осуществляться 
параллельно. Пока выполняются один или несколько процес¬ 
сов, схемы параллельной логики могут проводить анализ дру¬ 
гих существующих процессов с целью определения того, когда 
следует осуществлять коммутацию процессов и к какому про¬ 
цессу подключаться. Оснащение архитектуры сложными сред¬ 
ствами синхронизации тоже предоставляет возможность выпол¬ 
нять эти операции (например, постановку в очередь или снятие 
с очереди) параллельно с другой работой. 

Улучшенная структура операционной системы. Материал, из¬ 
ложенный в данном и нескольких предыдущих разделах, свиде¬ 
тельствует о тенденции к реализации некоторых базовых функ¬ 
ций операционной системы непосредственно в машине, т. е. аппа¬ 
ратными средствами. Это позволяет дать таким функциям более 
стабильную основу и формализованное определение. Архитекту¬ 
ра машины обычно лучше документирована и более тщательно 
определена, чем базирующееся на ней программное обеспечение. 
В результате операционная система становится менее сложной. 
Следует также учесть, что проектирование всех аппаратно реа¬ 
лизуемых механизмов сопровождается значительно более тща¬ 
тельным тестированием их работоспособности. Кроме того, аппа¬ 
ратная реализация функций программного обеспечения во мно¬ 
гом способствует устранению побочных эффектов этих функций, 
а также включению в программное обеспечение так называемых 
неортодоксальных интерфейсов. Указанные интерфейсы являются 
отклонениями от «стандарта» операционных систем и источни¬ 
ком дополнительных проблем современного системного про¬ 
граммирования. Все это позволяет с большим доверием отно¬ 
ситься к утверждениям о корректности работы вычислительной 
системы в целом. 

ТИПЫ АДРЕСАЦИИ 

Важной характеристикой архитектуры вычислительной машины 
являются типы адресации, используемые набором ее команд, 
т. е. адресация команд к своим операндам. Эта характеристика 
связана с проблемами, присущими не только последним дости¬ 
жениям в архитектуре ЭВМ, но и традиционным решениям; 
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речь идет об относительных достоинствах различных типов ад¬ 
ресации, представляемых моделями, ориентированными на ис¬ 
пользование стеков, регистров или памяти. Обсуждение до¬ 
стоинств и недостатков этих моделей [49—53] свидетельствует 
о том, что упомянутые проблемы не нашли еще своего оконча¬ 
тельного решения. 

Выбор типа адресации команд связан с поиском наиболее' 
эффективных способов представления (в пространстве) и обра¬ 
ботки (во времени) выражений. Важность этой проблемы не 
подлежит сомнению, так как вычисление значения выражения 
обычно является функцией, наиболее часто выполняемой вычис¬ 
лительной машиной. Например, вычисления выражений требу¬ 
ются следующим операторам языков высокого уровня: 

всем операторам присваивания (например, А = В; А = А + В);. 

всем операторам IF (таким, как IF(A = B)...; IF(A + B = 
—С)...); 

многим операторам DO (DO WHILE (А^В)); 

некоторым другим операторам (например, CALL 
XYZ(Q, А+В)). 

Согласно результатам одного исследования [54], операто¬ 
рами присваивания и IF являются 78% всех выполняемых опе¬ 
раторов, в другом исследовании [55] этот параметр указывает¬ 
ся равным 59%. Следовательно, эффективность вычисления вы¬ 
ражений в значительной степени определяет эффективность ис¬ 
пользования пространства памяти и машинного времени вычис¬ 
лительной системы. 

Поскольку существует несколько основных типов адресации- 
команд, каждый из них будет рассмотрен отдельно, а затем 
будет проведено их количественное и качественное сравнение. 
Отметим, что рассматриваемые здесь основные типы адресации' 
не исчерпывают всех возможных способов адресации, кроме то¬ 
го, иногда применяют их сочетания. Примером могут служить 
команды микропроцессора іАРХ 432, описываемого в части ѴГ 
данной книги. 

АДРЕСАЦИЯ ПОСРЕДСТВОМ РЕГИСТРОВ 

Архитектура вычислительной машины, использующей для адре¬ 
сации набор регистров общего назначения, лучше всего извест¬ 
на программистам. Здесь команды получают возможность ад¬ 
ресоваться к операндам, расположенным в одной из двух запо¬ 
минающих сред, — основной памяти или регистрах. Размер ре¬ 
гистра обычно фиксирован и совпадает с размером слова фи¬ 
зически реализованной основной памяти. К любому регистру 
можно адресоваться непосредственно, поскольку регистры пред¬ 
ставлены в виде массива запоминающих элементов. Количество, 
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регистров определяется архитектурой машины, а не конкретным 
вариантом ее реализации. Обычно регистров немного — 8 или 
Д6. Технологическая база регистров обеспечивает более высокое 
быстродействие последних по сравнению с основной памятью. 

Типичным является выполнение арифметических операций 
только в регистре; при этом команда содержит два операнда, 
размещаемые либо в регистрах, либо один из них находится в 
регистре, а другой — в основной памяти. Такие команды имеют 
следующие форматы: 

КОП РЕГ ПАМ 
КОП РЕГ РЕГ 

где КОП — код операции, РЕГ — номер регистра, ПАМ — ад¬ 
рес основной памяти. 

Не останавливаясь подробно на формате команд, отметим 
только, что ПАМ — это или линейный адрес памяти, или линей¬ 
ное смещение области памяти относительно адреса, указывае¬ 
мого специальным (базовым) регистром, или адрес ячейки до¬ 
мена санкционированного доступа и т. д. Будем полагать, что 
код операции помимо задания выполняемой операции указыва¬ 
ет также, какой из двух форматов используется. 

В качестве примера рассмотрим команды, генерируемые для 
оператора присваивания А: = В + С 
LOAD REG1.B 
ADD REGl.C 
STORE REG1.A 

Для проведения в дальнейшем сравнения типов адресации 
введем следующие условные обозначения: Р—размер кода опе¬ 
рации команд некой гипотетической архитектуры, использую¬ 
щей адресацию посредством регистров; R — размер адреса ре¬ 
гистра; S — размер адреса операнда, расположенного в основ- 
*юй памяти; D — средний размер операнда. 

АДРЕСАЦИЯ ПОСРЕДСТВОМ АККУМУЛЯТОРА 

Данный тип адресации подразумевает ориентацию архитекту¬ 
ры машины на использование для адресации единственного ре¬ 
гистра, называемого аккумулятором. В сущности, такая модель 
архитектуры является предельным вариантом архитектуры с ад¬ 
ресацией посредством регистров, когда количество последних 
сведено к одному регистру — аккумулятору. Он играет роль не¬ 
явно заданного операнда всех команд, имеющих одинаковый и 
единственный формат следующего вида: 

КОП ПАМ 
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В данном случае для оператора А: = В+С генерируются сле¬ 
дующие машинные команды: 

LOAD В 
ADD С 
STORE А 

При адресации посредством аккумулятора размер кода опе¬ 
рации команды не совпадает с размером кода операции коман¬ 
ды при адресации посредством регистров, поскольку в послед¬ 
нем случае код операции включает еще информацию о том, 
какой из двух возможных форматов команд используется. Архи¬ 
тектура машины с адресацией посредством аккумулятора позво¬ 
ляет ограничиться меньшим набором команд, так как при этом 
отсутствуют команды формата «регистр-регистр». Поскольку в 
проводимых здесь количественных оценках внимание уделяется 
только командам, используемым для вычисления значения вы¬ 
ражений (т. е. команды, относящиеся к управлению функциони¬ 
рованием системы, игнорируются), размер кода операции 
команды с адресацией посредством аккумулятора может быть, 
определен как Р—1, где Р — код операции команды машины с 
адресацией посредством регистров общего назначения. Следо¬ 
вательно, в данном случае код операции может быть короче на 
1 бит. Если же предположить, что независимо от типа адреса¬ 
ции длина команды должна равняться одной и той же величи¬ 
не, то можно сказать, что в распоряжение архитектуры с адре¬ 
сацией посредством аккумулятора поступает дополнительно 
1 бит (от каждой команды). 

АДРЕСАЦИЯ ПОСРЕДСТВОМ СТЕКА 
С ИСПОЛЬЗОВАНИЕМ БЕЗАДРЕСНЫХ КОМАНД 

Адресация этого типа основана на использовании не аккумуля¬ 
тора или набора регистров, а стека. (Рассматриваемое здесь 
применение стека не обязательно должно быть подобно исполь¬ 
зованию стеков рассмотренным ранее механизмом управления 
подпрограммами.) В общем случае команды неявно адресуются 
к элементу стека, расположенному на его вершине, или к двум 
верхним элементам стека. Такие команды могут иметь один на 
следующих форматов: 

КОП ПАМ 
КОП 

К командам первого формата относятся команды PUSH w 
STORE. По команде PUSH из области основной памяти, адре¬ 
суемой ее операндом, извлекается копия содержимого и загру¬ 
жается в стек; при этом на одну позицию вниз сдвигаются все 
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остальные элементы стека. По команде STORE из стека вытал¬ 
кивается элемент, расположенный на его вершине, и помещается 
в область памяти, адресуемую операндом этой команды. 

Команды второго формата являются безадресными и имеют 
только код операции. Обычно они неявным образом адресуются 
к одному или двум элементам вершины стека. Типичными 
командами этой группы являются следующие: 

ADD — сложение значений двух верхних элементов стека, 
удаление их из стека с последующей записью в него получен¬ 
ной суммы; 

СОМР — изменение на обратный знака элемента на вершине 
стека; 

EQUAL —сравнение значений двух верхних элементов сте¬ 
ка, извлечение их из стека и запись в него логической величины 
TRUE или FALSE в зависимости от результата сравнения; 

POP — извлечение («выталкивание») из стека элемента, рас¬ 
положенного на его вершине. 

Последовательность машинных команд, генерируемых для опе¬ 
ратора А: = В + С, в этом случае имеет следующий вид: 

PUSH В 

PUSH С 

ADD 

STORE А 

Машина с подобной адресацией располагает примерно таким 
же количеством различных команд, как и при использовании 
адресации посредством аккумулятора, но их меньше, чем имеет 
машина с адресацией посредством регистров общего назначе¬ 
ния. Следовательно, в данном случае размер кода операции то¬ 
же равен ~ (Р—1). 

Прежде чем сравнивать рассматриваемый тип адресации с 
другими типами, следует проанализировать вопрос о реализации 
стека на практике. Теоретически часто полагают, что объем сте¬ 
ка безграничен. Однако это не соответствует реальным возмож¬ 
ностям аппаратных средств ЭВМ. Поэтому обычно предлагают¬ 
ся следующие компромиссные решения: 

1) выполнить стек в виде конечного, фиксированного набора 
регистров, расположенных в процессоре; 

2) выполнить стек в виде конечного, фиксированного набора 
регистров, расположенных в процессоре, используя область ос¬ 
новной памяти как вспомогательное средство (буфер) в случае 
переполнения набора регистров; 

3) выполнить стек в виде области памяти. (Примером может 
служить архитектура машин, обсуждаемая в частях II и III дан¬ 
ной книги.) 
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Практическое осуществление того или иного предложения 
отражается на пропускной способности тракта «процессор — па¬ 
мять» и поэтому подлежит отдельному изучению. Первое из 
предлагаемых решений назовем стеком на регистрах, послед¬ 
нее— стеком в памяти. Они будут описаны отдельно. Второе 
предлагаемое решение может быть рассмотрено как некоторая 
аппроксимация первого. 

АДРЕСАЦИЯ ПОСРЕДСТВОМ СТЕКА 
С ИСПОЛЬЗОВАНИЕМ ОДНОАДРЕСНЫХ КОМАНД 

Адресация этого типа подобна последней из рассмотренных вы¬ 
ше, за исключением следующей особенности: многие безадрес¬ 
ные команды (состоящие только из кода операции) имеют одно¬ 
адресный эквивалент. Например, формат такой команды ADD 
представляется в виде 

ADD ПАМ 

При выполнении этой команды содержимое области памяти, 
адресуемой операндом ПАМ, добавляется к значению элемента 
на вершине стека с последующим замещением верхнего элемен¬ 
та полученной суммой. Команды этого типа, генерируемые для 
оператора А: = В + С, имеют следующий вид: 

PUSH В 

ADD С 

STORE А 

Поскольку для адресации данного типа желательно сохране¬ 
ние безадресных команд, наличие двух возможных форматов 
команд обусловливает размер их кода операции, равный Р. 

Итак, при рассмотрении проблемы реализации стека возни¬ 
кают две задачи: выполнение стека на регистрах и в памяти. 

АДРЕСАЦИЯ ТИПА «ПАМЯТЬ-ПАМЯТЬ» 

Адресация данного типа не предполагает в архитектуре машины 
явного определения аккумулятора, регистров или стека; все опе¬ 
ранды команд адресуются к областям основной памяти. Такие 
команды в большинстве случаев бывают двух- или трехадресны¬ 
ми. Формат двухадресных команд имеет следующий вид: 

КОП ПАМ ПАМ 

Отметим, что адресация этого типа может быть дополнена 
небольшим количеством одноадресных команд, например для 
вычисления дополнения. Количество различных двухадресных 
команд, необходимых для реализации архитектуры машины с 
адресацией типа «память-память», очевидно, несколько меньше 
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количества необходимых команд при адресации посредством 
стека: в первом случае не нужны команды записи в стек и изв¬ 
лечения из него. Однако указанная разница незначительна, и 
поэтому размер кода операции двухадресных команд может 
быть оценен величиной Р—1. 

Другой возможный вид команд с адресацией типа «память- 
память» имеет формат 

КОП ПАМ ПАМ ПАМ 

Команды такого формата называют трехадресными, причем 
два операнда, как правило, являются «источниками» исходных 
данных, а третий — «приемником» результата. Архитектура ма¬ 
шины с набором подобных трехадресных команд имеет код 
операции, размер которого равен ~ (Р—1). 

Существует еще одна разновидность архитектуры ЭВМ, ос¬ 
нованная на использовании адресации типа «память-память». 
Набор ее команд включает как двух-, так и трехадресные 
команды, а сама архитектура условно называется 2/3-адресной 
типа «память-память». Поскольку в ней используются два типа 
форматов команд (двух- и трехадресных), коду операции 
команды необходим дополнительный бит для указания типа ее 
формата, а поэтому размер кода операции можно принять рав¬ 
ным ~Р. 


количественный анализ 

Характеристики девяти типов адресации команд, подлежащие 
анализу, приведены в табл. 4.2. Следует обратить внимание на 
то, что некоторые характеристики, в частности объем пересы¬ 
лаемых данных, приходящийся на одну команду, меняются в за¬ 
висимости от формата команд. 

При проведении анализа будем рассматривать девять вари¬ 
антов архитектуры гипотедической вычислительной машины, 
идентичных во всем, за исключением типа адресации, используе¬ 
мого командами машины. Упомянутая идентичность подразуме¬ 
вает наличие у машин одинакового набора команд (за исключе¬ 
нием тех команд, в которых применяется специфический для 
данной архитектуры способ адресации, например команды 
LOAD, PUSH) и эквивалентных размеров S адресов операндов 
в основной памяти. 

Поскольку эффективность того или иного типа адресации, 
используемого командами, как будет показано, зависит от вида, 
размера и сложности вычисляемых выражений, анализ должен 
проводиться с привлечением выражений с различными характе¬ 
ристиками, а также с учетом частоты, с которой такие выраже* 
ния встречаются. 
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Таблица 4.2. Характеристики типов адресации команд 


Тип адресации 

Количество 

различйых 

форматов 

Длина 

команды, бит 

ресылаемых 
данных на 
одну коман¬ 
ду 1 ) 

Посредством регистра (РЕГ) 

2 

P + R + S 

D 

Посредством аккумулятора (АКК) 

1 

Р — 1 + S 

D 

Посредством стека на регистрах и 
безадресных команд (СРБА) 

Посредством стека в памяти и безад- 

2 

Р —1 + S 
р — 1 

D 

0 

ресных команд (СПБА) 

Посредством стека на регистрах и 

2 

Р— 1 + S 
р — 1 

2D 

2D или 3D 2 > 

одноадресных команд (СРОА) 

Посредством стека в памяти и одно¬ 

2 

P + S 

р 

D 

0 

адресных команд (СПОА) 

«Память-память» с использованием 

2 

P + S 
р 

2D или 3D 2 > 
2D или 3D 2) 

двухадресных команд (ППДА) 
«Память-память» с использованием 

1 

Р — 1 + 2S 

2D или 3D 1 » 

трехадресных команд (ППТА) 
«Память-память» с использованием 
двух- и трехадресных команд 

1 

P-1+3S 

2D или 3D S > 

(ППДТА) 

2 

P + 2S 

P + 3S 

2D или 3D 2 > 
2D или 3D 2 > 


') Подсчитываются только пересылки данных в памяти (исключаются пересылки меж¬ 
ду регистрами и подобные операции с аккумулятором и стеком). 

1 ) Для таких команд, как PUSH и MOVE, объем пересылаемых данных составляет 
2D, а для команд, подобных команде ADD, равен 3D. 


Начнем анализ, взяв за основу для сравнения следующие 
операторы присваивания (выбор этих операторов из почти бес¬ 
конечного набора возможных операторов станет понятным 
позже): 

1) А: = В; 2) А:=А+В; 3) А: = В + С; 4) A: = B + C+D; 

5) A:=(B + C)*(iD+E); 6) A: = B + C+D + E; 7) А:=(В*С+ 
+D*E)*F+G; 

Оставим пока на время вопрос о частоте выполнения этих 
выражений. В табл. 4.3 показано количество команд, необходи¬ 
мых для выполнения операторов машиной с архитектурой того 
или иного вида. Две разновидности адресации посредством сте¬ 
ка в памяти не рассматриваются, поскольку от адресации по¬ 
средством стека в регистрах они отличаются толыю пересылкой 
данных из памяти и в память. Отметим, что при адресации ти- 
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Таблица 4.3. Количество команд, необходимых для выполнения операторов 
машинами с разными видами архитектуры 



чество команд. 

В табл. 4.4 в символической форме представлены размеры 
генерируемых команд: размер каждой команды указан в виде 
алгебраического выражения, составленного из переменных Р 
(размер кода операции в соответствии с конкретным вариан¬ 
том архитектуры машины), R (размер адреса регистра) н 


Таблица 4.4. Размеры команд для машин различной архитектуры 


оператора 

Размер команды, бит 

РЕГ 

АКК 

СРБА 

СРОА 

1 

2Р + 2R + 2S 

2Р + 2S — 2 

2Р + 2S — 2 

2Р + 2S 

2 

ЗР + 3R + 3S 

ЗР + 3S — 3 

4Р + 3S — 4 

ЗР + 3S 

3 

рР + 3R + 3S 

ЗР + 3S — 3 

4Р + 3S — 4 

ЗР + 3S 

4 

ЗР + 3R + 3S 

4Р + 4S — 4 

6Р + 4S — 6 

4Р + 4S 

5 

6Р + 7R + 5S 

7Р + 7S — 7 

8Р + 5S - 8 

6Р + 5S 

6 

5Р + 5R + 5S 

5Р + 5S — 5 

8Р + 5S — 5 

5Р + 5S 

7 

8Р + 9R + 7S 

9Р + 9S — 9 

12Р + 7S — 12 

8Р + 7S 


оператора 

Размеры команды, бвт 

ППДА 

1 ППТА 

ППДТА 

1 

Р + 2S — 1 

P + 2S — 1 

P + 2S 

2 

Р + 2S - 1 

Р + 3S — 1 

Р + 2S 

3 

2Р + 4S — 2 

P + 3S— 1 

Р + 3S 

4 

ЗР + 6S — 3 

2Р + 6S — 2 

2P + 5S 

5 

5Р + 10S — 5 

ЗР + 9S — 3 

3P + 8S 

6 

4P + 8S — 4 

3P + 9S — 3 

і 3P + 7S 

7 

7Р + 14S — 7 

5Р + 15S — 5 

5Р + 12S 
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Таблица 4.5. Число операций ЧТЕНИЕ и ЗАПИСЬ для данных, размещаемых 
в памяти (пересылка данных длиной D) 



S (размер адреса операнда, расположенного в основной па¬ 
мяти). 

В табл. 4.5 приведены значения числа операций с данными, 
размещаемыми в основной памяти. В большинстве случаев 
каждое такое значение равно коэффициенту при переменной S 
в соответствующей позиции табл. 4.4. Различия наблюдаются 
для команд, использующих адресацию посредством стека в па¬ 
мяти или адресацию типа «память-память». Например, для вы¬ 
полнения команды ADD с адресацией посредством стека в па¬ 
мяти при безадресном формате необходимо три обращения к 
памяти. Такое же количество обращений к памяти требуется 
для выполнения двухадресной команды ADD с адресацией типа 
«память-память». Взятые вместе табл. 4.4 и 4.5 характеризуют 
использование тракта «процессор-память». 

Теперь необходимо рассмотреть относительную частоту ис¬ 
пользования знаков операций в семи операторах, выбранных в 
качестве примера. В табл. 4.6 приведены усредненные статисти¬ 
ческие данные, полученные в результате проведенных исследо¬ 
ваний [54, 55]. Первая группа данных показывает число зна¬ 
ков операций, используемых справа от знака операции при- 


Таблица 4.6. Статистические данные, отображающие сложность оператора 
присваивания языка высокого уровня 


Количество 

Относительная частота 
использования знаков 
операций, % 

Знаки арифметических 
операций 

Относительное 
количество зна¬ 
ков операций, % 

0 

72,1 

Знаки одноместных 


1 

20,5 

операций 

1,5 

2 

3,8 

Знаки двухместных 

84,0 

3 

3,3 

операций: + и — 

4 

0,3 

Знаки двухместных 
операций: *, / и ** 

14,5 
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сваивания; вторая группа — значения относительной частоты 
использования знаков арифметических операций. 

Согласно данным табл. 4.6, частота использования операто¬ 
ра 1 (А:=В) равна 72,1%. Совместная частота использования 
операторов 2 и 3 составляет 20,5%. Эти операторы объединены 
потому, что машины с различными типами адресации команд 
используют их с разной эффективностью. Грубые оценки [51] 
показывают, что частота выполнения оператора 2 равна 14,4%, 
а оператора 3—6,1%. У оператора 4 два знака операции, а 
поэтому частота его использования составляет 3,8%. Два опера¬ 
тора (5 и 6) имеют по три знака операции каждый. Однако 
один из них (оператор 5) требует соблюдения определенной 
последовательности выполнения операций, для другого (опера¬ 
тора 6) порядок реализации операций не имеет значения. Вот 
почему эти два оператора рассматриваются вместе. Совместная 
частота их использования, согласно табл. 4,6, равна 3,3%. Для 
определения частоты использования каждого из указанных опе¬ 
раторов необходимо знать вероятность, с которой в выражении 
с тремя знаками операций встречаются операции равной оче¬ 
редности выполнения (например, все операции умножения и 
деления или сложения и вычитания). Если воспользоваться 
данными табл. 4.6, то указанную величину можно определить 
следующим образом: 0,84 3 + 0,145 3 да60%. Следовательно, часто¬ 
та использования операторов 5 и 6 равна соответственно 1,3 и 
2,0%. Оператор 7, содер¬ 
жащий пять знаков опе¬ 
раций, позволяет полу¬ 
чить представление о 
всех прочих разновиднос¬ 
тях оператора присваива¬ 
ния; частота его исполь¬ 
зования составляет 0,3%. 
Значения частоты исполь¬ 
зования всех перечислен¬ 
ных операторов сведены 
в табл. 4.7. 

На основании данных 
габл. 4.4 и 4.7 можно вы¬ 
вести ряд формул для оценки некоторых параметров вычисли¬ 
тельных машин с адресацией различного типа, выполняющих 
операторы присваивания рассмотренного вида. Эти формулы 
сведены в табл. 4.8. 

Табл. 4.9 содержит сравнительные характеристики различ¬ 
ных типов адресации по нескольким параметрам. Представлен¬ 
ные в таблице значения получены путем вычисления по форму¬ 
лам. приведенным в табл. 4.8, с последующей нормализацией 


Таблица 4.7. Частота использования 
операторов присваивания различного вида 


Оператор 

Частота ис¬ 
пользования, 

% 

А: = В; 

72,1 

А:=А + В; 

14,4 

А: = В + С; 

6,1 

А: = В + С + D; 

3,8 

А:= (В + С) * (D + Е); 

1,3 

А: = В + С + D + Е; 

2,0 

A:=(B*C + D*E)*F + G; 

0,3 
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Таблица 4.8. Сравнение некоторых параметров выполнения операторов 
присваивания машинами с различными типами адресации 


Тип адресации 

Средний размер машин¬ 
ной команды, бит 

Средний объем данных, 
пересылаемых между па¬ 
мятью и процессором, бит 

Посредством регистров 
Посредством аккумуля- 

2,4Р + 2,4R + 2,4S 

2,4Р + 2,4R + 2,4S + 

+ 2.4D 

тора 

Посредством стека на ре¬ 
гистрах и безадресных 

2,4Р + 2.4S — 2,4 

2,4Р + 2,4S — 2,4 + 2,4D 

команд 

Посредством стека в па¬ 
мяти и безадресных 

2,8Р + 2.4S — 2,8 

2,8Р + 2,4S — 2,8 — 2,4D 

команд 

Посредством стека на ре¬ 
гистрах и одноадрес¬ 

2,8Р + 2.4S — 2,8 

2,8P + 2,4S — 2,8 + 6,0D 

ных команд 

Посредством стека в па¬ 
мяти и одноадресных 

2,4Р + 2,4S 

2,4P + 2,4S + 2,4D 

команд 

«Память-память» с ис¬ 
пользованием двухад¬ 

2,4Р + 2,4S 

2,4P + 2,4S + 5,2 

ресных команд 
«Память-память» с ис¬ 
пользованием трехад¬ 

1,ЗР + 2.5S — 1,3 

1.3P + 2.5S-1,3 + 2,9D 

ресных команд 
«Память-память» с ис¬ 
пользованием двух- и 

1,1Р + 2.6S — 1,1 

1.1P + 2.6S —1,1 +2,6D 

трехадресных команд 

1,1 Р + 2,4 S 

1,1P + 2,4S + 2,6D 


содержимого каждого столбца значений посредством приравни¬ 
вания единице наименьшего (наилучшего) из них. С точки зре¬ 
ния компактности команд (параметр S) наилучшей оказывает¬ 
ся адресация типа «память-память», а наихудшей — адресация 
посредством регистров общего назначения. Сравнение типов 
адресации по общему количеству пересылаемых битов между 
памятью и процессором (параметр М) не дает столь ясно вы¬ 
раженных результатов. Адресация типа «память-память» с ис¬ 
пользованием двух- и трехадресных команд оказывается наи¬ 
лучшей во всех трех случаях измерения параметра М, адреса¬ 
ция посредством стека в памяти — наихудшей, позиции осталь¬ 
ных типов адресации, классифицируемых по данному парамет¬ 
ру, не являются столь очевидными. 

Если воспользоваться теми же приближенными оценками, 
что и раньше, то можно считать несущественным 10%-ный раз¬ 
брос значений величин, содержащихся в таблице. Тогда ока¬ 
зывается, что типы адресации «память-память», посредством 
стека на регистрах безадресными и одноадресными командами, 
а также посредством аккумулятора оказываются наивысшего 
ранга по параметру М, несколько худшие результаты дает ад* 
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Таблица 4.9. Сравнение различных типов адресации по основным параметрам 


Тип адреаадии 

Нормализован¬ 
ный размер 
команды (пара¬ 
метр S) 

Нормализованный объем 
данных, пересылаемых 
между процессором и пас 
мятью (параметр М) 


Р= 8 
R = 4 
S= 12 

Р = 8 

R = 4 

S = 16 

D = 16 
Р= 8 

R =4 

S = 12 

D= 32 
Р= 8 

R =4 

S = 12 

D = 32 
Р = 8 

R = 4 

S = 16 

Посредством регистров 

1,53 

1,42 

1,21 

1,11 

1,10 

Посредством аккумулятора 
Посредством стека на регистрах 

1,21 

1,17 

1,06 

1,01 

1,01 

и безадресных команд 
Посредством стека в памяти и 

1,29 

1,23 

1,10 

1,04 

1,03 

безадресных команд 

Посредством стека на регистрах и 

1,29 

1,23 

1,82 

1,99 

1,91 

одноадресных команд 
Посредством стека в памяти и 

1,28 

1,22 

1,09 

1,03 

1,03 

одноадресных команд 
«Память-память» с использовани¬ 

1,28 

1,22 

1,66 

1,77 

1,72 

ем двухадресных команд 
«Память-память» с использовани¬ 

1,04 

1,04 

1,08 

1,09 

1,09 

ем трехадресных команд 
«Память-память» с использовани¬ 

1,03 

1,04 

1,02 

1,01 

1,02 

ем двух- и трехадресных команд 

1 

1 

1 

1 

1 


ресация посредством регистров и сравнительно плохие —адре¬ 
сация посредством стека в памяти. При сравнении по обоим 
параметрам S и М наилучшими оказываются типы адресации 
«память-память» с использованием трехадресных, а также 
двух- и трехадресных команд. К сделанным выводам следует 
относиться с осторожностью, поскольку они справедливы по 
отношению к параметрам в табл. 4.9 и не связаны с особенно¬ 
стями практической реализации адресации того или иного типа; 
анализ конкретной архитектуры машины и конкретного вари¬ 
анта ее реализации может привести к иным результатам. К по¬ 
добным выводам приходят авторы и другого исследования 
[56], где показано, что совместное использование различных 
типов адресации может привести к дальнейшему совершенст¬ 
вованию архитектуры вычислительной машины. 


КАЧЕСТВЕННЫЙ АНАЛИЗ 

Относительно сравнительных характеристик команд с различ¬ 
ными типами адресации к данным можно высказать еще не¬ 
сколько замечаний. Так, можно рассмотреть их влияние на 
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взаимосвязь оптимизации работы компилятора и архитектуры 
машины. Указанная оптимизация в значительной мере не зави¬ 
сит от архитектуры и может выполняться над программой, 
представленной на языке высокого уровня. Одной из сторон 
такой оптимизации, выполняемой с той или иной іполнотой ре¬ 
ализации ее возможностей, является типичная для большинст¬ 
ва компиляторов регистровая оптимизация, т. е. минимизация 
числа обращений к памяти путем удержания данных (напри¬ 
мер, численных значений переменных или фрагментов арифме¬ 
тических выражений) в регистрах на протяжении выполнения 
целого ряда команд. Сама природа такой оптимизации делает 
ее неприемлемой для машин, использующих адресацию посред¬ 
ством аккумулятора или стека, а также адресацию типа «па¬ 
мять-память». Однако для машин с адресацией посредством 
регистров общего назначения регистровая оптимизация позво¬ 
ляет улучшить значение параметра М. Но прежде чем ее ис¬ 
пользовать, необходимо принять во внимание следующие 
обстоятельства: во-первых, стремление к более высокой модуль¬ 
ности представления алгоритма решения задачи в машине сни¬ 
жает возможный эффект регистровой оптимизации; во-вторых, 
использование быстродействующей кэш-памяти, управляемой 
аппаратными средствами, позволяет добиться во многом эф¬ 
фекта регистровой оптимизации. 

Доводом против использования адресации посредством ре¬ 
гистров, стека или аккумулятора является наличие типичных 
для них ограничений на размеры операндов; последние должны 
иметь единственный фиксированный размер или в лучшем слу¬ 
чае небольшое число заранее установленных размеров. 

Применению адресации посредством стека на регистрах 
внутри процессора препятствует сложность ее реализации на 
практике. Принцип адресации с помощью стека обычно пред¬ 
полагает отсутствие ограничений на его объем. Обычным прак¬ 
тическим решением этой проблемы является применение не¬ 
большого набора регистров в процессоре и использование об¬ 
ласти основной памяти в качестве остальной части стека. На¬ 
пример, ЭВМ HP3000 [15] содержит четырехрегистровый стек 
в процессоре. Если в него необходимо загрузить более четырех 
данных, нижние данные пересылаются из регистров в основную 
память. Следствием этого является увеличение числа пересы¬ 
лок между памятью и процессором при вычислении значений 
сложных выражений. 

Наконец, необходимо напомнить о наличии недостатков, 
свойственных архитектуре машины, использующей регистры 
общего назначения. Некоторые из них, в частности функцио¬ 
нальное несоответствие регистров машины и представления 
данных в языках программирования, а также трудности отлад- 
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жи программ, относятся в равной мере и к архитектуре машин, 
использующих стеки и аккумуляторы. 

ОПЕРАЦИИ ВЫСОКОГО УРОВНЯ 

Наиболее очевидным решением проблемы сокращения семанти¬ 
ческого разрыва между архитектурой машины и языком про¬ 
граммирования является введение в состав набора команд ма¬ 
шины команд высокого уровня. Последние способны выполнять 
операции и функции, описываемые языками высокого уровня. 
Некоторые основные положения, уже изложенные в данной гла¬ 
ве, можно рассматривать как значительный шаг вперед в ука¬ 
занном направлении, поскольку они позволяют предоставить 
машине такие возможности, как выполнение операций по пре¬ 
образованию данных, индексированию массивов, вызову про-' 
цедур, синхронизации вычислительных процессов и т. д. Сфера 
применения операций высокого уровня включает обработку 
-строк символов, арифметические операции, обработку функцио¬ 
нальных элементов программ (например, итерационных про¬ 
цессов), редактирование программ, работу с ошибками, отсле¬ 
живание выполнения программ. 

Обработка строк символов приобретает особое значение 
вследствие ее широкого использования во многих программах. 
■Например, анализ работы компилятора языка АЛГОЛ-60 вы¬ 
числительной системы Burroughs В5500 [14] показал, что более 
трети времени выполнения программ затрачивается на опера¬ 
ции над строками символов. Такие операции, типичные для 
многих языков программирования, включают манипулирование 
частями строк, поиск заданной части строки в строках, соеди¬ 
нение строк и определение длины строк. 

Набор арифметических операций, включаемых в архитекту¬ 
ру машины, должен зависеть от используемого языка (языков) 
программирования и «внешнего мира» машины (решаемых за¬ 
дач). Если класс решаемых задач ориентирован на числовые 
расчеты, то целесообразно введение таких операций, как извле¬ 
чение корня, вычисление экспоненты и тригонометрических 
функций, быстрое преобразование Фурье и т. п. 

Рассматриваемая в последующих главах архитектура машин 
В1700/1800 и SWARD является хорошей иллюстрацией исполь¬ 
зования операций высокого уровня. 

МНОГОУРОВНЕВАЯ 
ЛЕКСИЧЕСКАЯ АДРЕСАЦИЯ 

Использование стеков для управления подпрограммами оказы¬ 
вает влияние на способы адресации к памяти. Например, опе¬ 
ранд в записи активации не имеет фиксированного адреса, по- 
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скольку запись активации может появляться в различных об¬ 
ластях стека в процессе выполнения программы. Вот почему в 
ЭВМ М68000 используется относительная адресация с помощью 
указателя кадра. Однако средства адресации этой машины 
позволяют обращаться прямо только к содержимому последне¬ 
го (текущего) кадра или записи активации, в то время как 
возможности архитектуры машины, адекватные средствам блоч¬ 
но-структурированных языков программирования, должны до 


procedure UGU is 

А : INTEGER; 

В : INTEGER-; 

procedure VVV is 

C : INTEGER; 

procedure XXX is 

D : INTEGER; 



A : = 
XXX; 


end XXX; 

begin 

XXX; 

end VVV; 

procedure WWW is 

E : INTEGER; 
begin 
E := 8; 



Address Reference 


( 0 , 1 ) 
(0,2) 
(0,3) 
(I. I) 


(0,4> 

0 , 1 ) 


Рис. 4.12. Пример использования многоуровневой 
лексической адресации. 


пускать адресацию к содержимому внешних записей актива¬ 
ции. Одним из путей решения этой проблемы является исполь¬ 
зование многоуровневой лексической адресации. 

Адрес лексического уровня представляет собой адресную 
пару, составленную из двух элементов: принадлежащего про¬ 
грамме лексического уровня переменной или операнда и индек¬ 
са (последовательного номера) этого операнда внутри данного 
лексического уровня. Поскольку лексическое упорядочение про¬ 
граммы и индексы операндов остаются статическими в течение 
выполнения программы (хотя физическое местоположение опе¬ 
рандов может изменяться), адрес лексического уровня можно 
использовать в машинных командах как адрес операнда. Ин¬ 
формация, необходимая для динамически преобразуемых адре¬ 
сов лексических уровней, может формироваться и поддержи¬ 
ваться машиной в физических (реальных) адресах. 

Этот принцип адресации лучше всего проиллюстрировать на 
поимепе. Для этой цели воспользуемся приведенной здесь про- 




драимой на языке Ада (рис. 4.12). Внешняя процедура нахо¬ 
дится на лексическом уровне 0. На этом уровне определены 
четыре идентификатора: А, В, WV и WWW (А и В —перемен¬ 
ные, VW и WWW— имена процедур; VW и WWW могут 
представлять собой дескрипторы соответствующих процедур). 
Согласно комментариям справа от текста программы, адресами 

Стек активации 


Рис. 4.13. Схема 
использования 
дисплей-регистров 
для определения 
местоположения записей 
активации. 


лексического уровня этих идентификаторов являются (0,1), 
(0,2), (0,3) и (0,4). 

Поскольку на лексическом уровне 1 имеются две процеду¬ 
ры, принадлежащие им идентификаторы имеют адресные пары 
вида (1, х). Подобным же образом одна из процедур имеет в 
свою очередь вложенный блок, содержащий адресные пары в 
форме (2, х). 

Если сравнивать однокадровую адресацию машины 68000 с 
многоуровневой лексической адресацией, то можно сказать, что 
последняя функционирует путем поддержания массива указа¬ 
телей кадров или записей активации. Этот массив часто назы¬ 
вают набором дисплей-регистров. Дисплей-регистр указывает 
местоположение записи активации, соответствующей блоку 
программы. Часть адреса, содержащая номер лексического 
уровня, используется для выбора дисплей-регистра; содержимое 
этого регистра добавляется к индексной части адреса для полу- 
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чения физического адреса. Заметим, что в случае вызова ре¬ 
курсивной процедуры дисплей-регистры не обязательно указы¬ 
вают на местоположение смежных записей активации. 

Для иллюстрации использования дисплей-регистров поло¬ 
жим, что упомянутая выше программа выполнила следующую 
последовательность операторов: 

VW;/XXX;/C:=8;/A:=D;/XXX; 

Содержимое стека активации показано на рис. 4.13. По мере 
того как записи добавляются в стек активации или удаляются 
из него, машина обновляет содержимое дисплей-регистров та¬ 
ким образом, чтобы каждый из них указывал местоположение 
записи активации, соответствующей каждому лексическому 
уровню. Машина «разрешает» (вычисляет) адрес (1, 1) для ма¬ 
шинной команды (команд), соответствующей оператору С: = 8, 
путем добавления единицы к содержимому дисплей-регистра 1. 
Для «разрешения» адреса (0,1) она добавляет единицу к содер¬ 
жимому дисплей-регистра 0. 

Хотя многоуровневая лексическая адресация и включена в 
рассмотрение, ее применение в будущем остается под вопро¬ 
сом. Одной из причин таких сомнений является тот факт, что 
ее основное назначение — решение проблемы определения об¬ 
ластей действия имен, например ситуаций, когда некоторые 
переменные используются во внутреннем блоке, не будучи ів нем 
описанными, и поэтому совместно используются как глобальные 
с некоторым внешним блоком. А именно это в настоящее время 
считается многими разработчиками языков программирования 
и системными программистами нежелательным. 


УПРАЖНЕНИЯ 

4.1. Какая конструкция языка программирования может препятствовать 
реализации на практике архитектуры машины с теговой памятью? 

4.2. Чтобы удостовериться в том, что принцип организации памяти по¬ 
средством тегов сокращает, а не увеличивает потребность в памяти, вычис¬ 
лите значение параметра R (среднее число обращений к операнду в машин¬ 
ных командах), воспользовавшись имеющейся в вашем распоряжении прог¬ 
раммой. Поскольку анализу подлежат не операторы исходной программы, а 
генерируемые машинные команды, воспользуйтесь компилятором, который мо¬ 
жет «выдать» листинг программы на языке ассемблера. 

4.3. Используя такой же подход, как и при анализе требований к памя¬ 
ти с теговой организацией, положим, что машина X располагает командами, 
имеющими 8-битовый код операции и два 4-битовых поля, задающих длину 
операндов (подобный формат в Системе 370 имеют команды десятичной 
арифметики и обработки строк символов, используемые, например, при вы¬ 
полнении программ на языке КОБОЛ). Положим также, что некоторая ма¬ 
шина Y имеет команды, инвариантные к типу обрабатываемых данных и со¬ 
стоящие из 6-битового кода операции при условии, что каждый операнд, рас¬ 
полагающийся в памяти, имеет 8-битовый тег (определяющий тип данных и 
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размер занимаемой ими области памяти). Пусть каждая команда обраща¬ 
ется к двум операндам, причем на каждый операнд в среднем приходится R 
обращений. Определите, при каком значении R машине Y требуется меньший 
объем памяти. 

4.4. Воспользуемся исходными данными упражнения 4.3 и положим, что 
R=10, адреса операндов занимают 16 бит, средний размер операнда равен 
32 бит (не считая тег). Определите разницу объема памяти, занимаемого од¬ 
ной и той же программой в машинах X и Y. 

4.5. Сформулируйте условия выполнения команды EXECUTE Системы 
370, если бы память этой вычислительной системы имела теговую организа¬ 
цию. 

4.6. При описании одноуровневой памяти упоминалось, что хотя модель 
этой памяти и допускает включение в нее устройств ввода-вывода без па¬ 
мяти, осуществление этого сопровождается появлением «двусмысленностей» 
в правилах функционирования такой модели. Например, для представления 
в такой модели устройства чтения перфокарт необходимо определение спе¬ 
циального 80-символьного поля в качестве «вершины» очереди, образованной 
записями, держателем которых является устройство чтения перфокарт. Об¬ 
ращение к этому полю имеет эффект чтения очередной карты, поскольку со¬ 
держимое поля представляет собой содержимое карты. Проанализируйте не¬ 
достатки такой модели. 

4.7. Для оператора А:= (B + C)*(D+E) определите команды, которые ге¬ 
нерируют машины, использующие адресацию посредством регистров, аккуму¬ 
лятора, стека с безадресными или одноадресными командами, а также адре¬ 
сацию типа «память-память» с двух-, трехадресными или совместно двух- и 
трехадресными командами. 
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ЧАСТЬ II 

АРХИТЕКТУРА, ОРИЕНТИРОВАННАЯ 
НА ЯЗЫК ПРОГРАММИРОВАНИЯ 


ГЛАВА в 

УЧЕБНАЯ ПЛ-МАШИНА 

Чтобы проиллюстрировать основные идеи, изложенные в час¬ 
ти I книги, рассмотрим учебную ПЛ-машину 1 ) [1]. Первона¬ 
чально эта машина предназначалась для демонстрации возмож¬ 
ности оптимизации, или настройки, архитектуры ЭВМ, ориенти¬ 
рованной на язык программирования. Это обстоятельство яв¬ 
ляется причиной некоторых особенностей данной машины. 
Во-первых, машина физически не реализована и существует 
только на бумаге. Во-вторых, ее архитектура не является за¬ 
вершенной, цельной: отсутствуют, например, некоторые функ¬ 
ции, которые могли бы понадобиться при нормальной работе 
операционной системы. В данной главе рассматривается пер¬ 
воначальная неоптимизированная версия архитектуры, а опти¬ 
мизация архитектуры такого типа, как пример оптимизации 
архитектуры ЭВМ, описывается в гл. 20. Перечисленные выше 
особенности не препятствуют достижению сформулированных 
выше целей, поскольку учебная ПЛ-машина оказывается про¬ 
стой и удобной для иллюстрации многих основных положений, 
рассматриваемых в части I книги. 

Архитектура ПЛ-машины ориентирована на язык програм¬ 
мирования, являющийся подмножеством языка ПЛ/1, которое 
не полностью совместимо с базовым языком. Пользуясь терми¬ 
нологией, введенной в гл. 4, можно сказать, что эта машина 
имеет память с теговой организацией, дескрипторы информаци¬ 
онных объектов, стеки для вычисления выражений, средства 
работы с подпрограммами, управляемую языком ПЛ/1 память, 
многоуровневую лексическую адресацию. 

УЧЕБНЫЙ ЯЗЫК пл 

Поскольку архитектура учебной ПЛ-машины ориентирована на 
учебный язык ПЛ, знакомство с машиной лучше всего начать 
с краткого описания структуры этого языка. В табл. 5.1 приве- 


ч Сочетание ПЛ происходит от английского PL (Programming Langu¬ 
age), что означает «язык программирования». — Прим, перев. 
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Таблица 5.1. Учебный язык ПЛ 


і Операторы 

Типы данных 

Встроенные функции 

Операции 

PROCEDURE 

FIXED 

ABS 

+ 

BEGIN 

FLOAT 

ATAN 


RETURN 

BIT 

BIT 


END 

CHARACTER 

CHARACTER 

/ 

DO 

LABEL 

COS 


DO WHILE 

ENTRY 

DUMP 

< 

DO CASE 

Оператор итератив- 

Scalar 

E-FORMAT 

> 

ного цикла DO 
CALL 

GO TO 

DECLARE 

Оператор присваива¬ 
ния 

IF 

ALLOCATE 

FREE 

Array 

END-OF-DATA 

EXP 

FIXED 

FLOAT 

INDEX 

LENGTH 

LOG 

MAX 

MIN 

MOD 

RANDOM 

SIGN 

SIN 

SQRT 

SUBSTR 

TAN 

TIME 

UNDEFINED 

, II IV ЛІ- 

■ѵлг гг 


дены операторы, типы данных, встроенные функции и знаки 
операций учебного языка ПЛ. 

Тип данных FIXED эквивалентен типу FIXED BINARY (31,0) 
языка ПЛ/1, тип данных FLOAT эквивалентен типу FLOAT 
BINARY (21), BIT аналогичен BIT (1), a CHARACTER- 
CHARACTER (4095) VARYING. 

Все переменные, за исключением массивов, размещаются в 
памяти автоматически. Все массивы размещаются в памяти, 
управляемой языком ПЛ/1, т. е. в области (или областях па¬ 
мяти), выделяемой и освобождаемой с помощью операторов 
ALLOCATE и FREE. 

Операторы учебного языка ПЛ достаточно точно соответст¬ 
вуют аналогичным операторам языка ПЛ/1. Программа может 
быть разделена на части с помощью блоков типа BEGIN, а 
также внутренних процедур и процедур-функций. Оператор GO 
ТО рассматриваемого языка имеет более ограниченные возмож¬ 
ности, чем аналогичный оператор языка ПЛ/1; адресат, кото¬ 
рому он передает управление, не может находиться внутри со- 
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ставных операторов (например, предложения THEN или ELSE, 
цикла DO). 

При определении значений арифметических и логических 
выражений, а также строк символов здесь, как и в языке ПЛ/1, 
используются весьма гибкие правила автоматического преобра¬ 
зования данных. Правила выполнения арифметических опера¬ 
ций над массивами в учебном языке ПЛ такие же, как и в язы¬ 
ке ПЛ/1. 

Учебный язык ПЛ представляет пользователю также 25 
встроенных функций, подобных аналогичным функциям языка 
ПЛ/1. Как и в языке ПЛ/1, некоторые из этих функций могут 
использоваться в качестве псевдопеременных, например появ¬ 
ляться в первой части оператора присваивания. Встроенная 
функция INPUT и псевдопеременная OUTPUT семантически 
эквивалентны операторам GET LIST и PUT LIST языка ПЛ/1. 
Функции BIT, CHARACTER, FIXED и FLOAT используются 
для преобразования данных, функции INDEX, LENGTH и 
SUBSTR — для работы со строками данных, функция 
UNDEFINED — для проверки того, задано ли значение пере¬ 
менной. 

СТРУКТУРА ПАМЯТИ 

учебной пл-машины 

Изучение архитектуры машины лучше всего начинать с прин¬ 
ципов организации ее памяти. С точки зрения разработчика 
компилятора и программиста, составляющего программы на 
машинном языке, учебная ПЛ-машина содержит, как показано 
на рис. 5.1, семь различных запоминающих устройств (каждое 
из которых называется также памятью), четыре специальных 
регистра и набор из 16 регистров. Каждое запоминающее 
устройство или регистр имеет определенное назначение. Все они 
между собой логически связаны, благодаря тому, что информа¬ 
ция, находящаяся в одних из них, указывает местоположение 
соответствующей информации в других. (Существующие связи 
показаны на рис. 5.1 стрелками). 

В учебной ПЛ-машине не реализован принцип «основной 
памяти». Наибольший интерес представляет стековая память 
данных (data stack memory). Нижняя часть этой памяти ис¬ 
пользуется как стек (принцип работы которого «поступивший 
первым обрабатывается последним») для вычисления выраже¬ 
ний и размещения информации о местоположении выполняемых 
в текущее время процедур, функций и блоков BEGIN. Ре¬ 
гистр — указатель стековой памяти данных всегда содержит 
информацию об адресе слова, находящегося на вершине этого 
стека. Верхняя часть стековой памяти данных управляется ап- 




Рис. 5.1. Структура памяти учебной ПЛ-машины. 

паратными средствами; она используется для размещения эле¬ 
ментов массивов. 

Стековая память данных —это так называемая теговая па¬ 
мять. Слово этой памяти длиной 39 бит состоит из 7-битового 
поля, содержащего тег (указатель типа данных), и 32-битового 
поля, включающего данные (рис. 5.2). Если у тега бит и ра¬ 
вен 1, то слово содержит неопределенную величину; если же 
единичное значение имеет бит р или а, то слово — указатель 
процедуры (функции) или массива соответственно. Остальные 
четыре бита тега содержат информацию о типе данных. 

Содержимое 32-битового поля данных интерпретируется в за¬ 
висимости от значения тега (табл. 5.2). В некоторых случаях 
это поле интерпретируется как состоящее из двух отдельных 
полей длиной 12 и 20 бит. Содержимое этих полей принято 
указывать в скобках. 

С целью упрощения объяснения назначения некоторых из 
рассматриваемых слов памяти массивы представлены как ука¬ 
затели элементов массивов, строки символов как дескрипторы 
строк символов, адреса переменных как дескрипторы косвенной 
адресации, адреса элементов массивов как дескрипторы элемен¬ 
тов массивов и адреса сегментов объектной программы как 
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Слово стековой памяти данных 
1114 12 20 



Элемент памяти дескрипторов массива 
для двумерного массива 

_16__ 16 

Указатель первого эле¬ 
мента массива в стековой Размерность 

памяти данных 

Нижняя граница верхняя граница Масштабный 

индекса индекса множитель 

Нижняя граница Верхняя граница Масштабный 

индекса индекса множитель 


Слово стека указателей сегментов программы 


12 20 13 16 



Слово памяти таблицы символических имен 



Слово памяти таблицы областей действия переменных 


8 8 8 4 



Указатель дескрип¬ 
тора массива для 
/ предыдущего рас- 
12 / пределения памяти 

- ~Г - 1 для массива 


Слово стека указателей активизируемых сегментов программы 
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Таблица 5.2. Содержимое слов стековой памяти данных 


Метка 

Содержимое поля данных 

бит U = 1 

Неопределенная величина 

бит р = 1 

Дескриптор сегмента программы (длина сегмента, адрес 
сегмента в памяти сегментов программ и строк данных) 

бит а = 1 

Указатель массива (не используется, адрес элемента в па¬ 
мяти дескрипторов массивов) 

тип = fixed 

Двоичное целое со знаком 

тип = float 

Двоичное число со знаком, представленное в форме с пла¬ 
вающей точкой 

тип = bit 

Булева величина («истинно» или «ложно») 

тип = char 

Дескриптор строки символов (длина строки, адрес строки 
в памяти сегментов программ и строк данных) 

тип = labc‘> 

Дескриптор метки, представляющей собой константу (сме¬ 
щение в сегменте программы, адрес сегмента программы 
в памяти сегментов программ и строк данных) 

тип = labv 2 > 

Дескриптор метки, представляющей собой переменную 
(смещение в сегменте программы, адрес сегмента прог¬ 
раммы в памяти сегментов программ н строк данных) 

тип = star 

Значение отсутствует (индекс массива задан в виде *) 

тип = ind 

Дескриптор косвенного адреса (адрес элемента стека ука¬ 
зателей областей намяти активных сегментов програм¬ 
мы, смещение относительно содержимого регистра — ука¬ 
зателя стековой памяти данных) 

тип •= arlm 

Дескриптор элемента массива (адрес элемента в памяти 
дескрипторов массивов, смещение элемента в массиве) 


') Label constant. — Прим, перев. *) Label varying. — Прим, перев. 


дескрипторы сегментов программы. Слово star («звездочка») 
используется для указания на представление индекса массива 
знаком *, как это делается в выражениях языка ПЛ/1, а имен¬ 
но А(М). 

Память сегментов программ и строк данных (string segment 
memory) состоит из слов длиной 8 бит и содержит объектные 
программы и строки символов. Объектные программы хра¬ 
нятся в виде одного или нескольких сегментов. Отдельный сег¬ 
мент может представлять процедуру, функцию, блок BEGIN, 
тело цикла DO, предложение THEN или ELSE оператора IF. 

Память дескрипторов массивов (array descriptor memory) 
содержит дескрипторы элементов массивов. Очередной дескрип¬ 
тор «вводится» в эту память аппаратно каждый раз при дина¬ 
мическом размещении массива. Каждый дескриптор представ¬ 
лен D + 1 смежными словами памяти, где D — размерность мас¬ 
сива. На рис. 5.2 показан дескриптор двумерного массива. Пер¬ 
вое поле содержит адрес первого элемента массива в стековой 
намяти данных. Последующие слова содержат информацию о 
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каждом измерении массива, т. е. определяют минимальное и 
максимальное граничные значения индекса и значение мас¬ 
штабного множителя, используемого для вычисления расстоя¬ 
ния между элементами массива в этом измерении. Третье поле 
в первом слове дескриптора используется для работы с па¬ 
мятью, управляемой языком ПЛ/1. (Например, если массив А 
уже размещен, а затем размещается опять, то существуют два 
дескриптора массива А, причем в текущем дескрипторе в дан¬ 
ном поле формируется ссылка на предыдущий дескриптор.) 

Стек указателей сегментов программы (program segment 
stack) используется для размещения информации об активных 
(выполняющихся в данный момент) сегментах программы. Ис¬ 
ходная программа разделяется компилятором на один или не¬ 
сколько сегментов. Каждая процедура, функция, блок BEGIN, 
предложение THEN, предложение ELSE, тело цикла DO пред¬ 
ставляются в виде отдельных сегментов программы. Причины 
представлений предложений THEN, ELSE и цикла DO как от¬ 
дельных сегментов объясняются в следующей главе; там же по¬ 
казано, что это является недостатком архитектуры данного типа. 

Указатель сегмента программы помещается в стек всякий 
раз, когда сегмент начинает выполняться; указатель, находя¬ 
щийся на вершине стека, удаляется, как только завершается 
выполнение сегмента. Регистр—указатель стека указателей 
сегментов программы всегда адресует к элементу, находящему¬ 
ся на вершине этого стека. Пользуясь терминологией, принятой 
для Системы 370, все содержимое стека указателей сегментов 
программы, в том числе и элемент, находящийся на вершине 
стека, можно рассматривать как PSW 1 ) машины, поскольку оно 
определяет текущее состояние программы. Четыре поля стека 
указателей сегментов программы, показанные на рис. 5.2, до¬ 
статочно понятны и не требуют дополнительных объяснений. 
Последнее поле предназначено для размещения величины, ко¬ 
торая во время выполнения первой команды данного сегмента 
находится в регистре — указателе стековой памяти данных. 

Исходное содержимое памяти таблицы символических имен 
(symbol table memory) устанавливается компилятором или за¬ 
грузчиком программ. Эта память используется машиной при 
выделении локальной памяти для сегмента. 

Каждому элементу таблицы символических имен соответст¬ 
вует идентификатор или константа исходной программы. Фор¬ 
мат элемента таблицы представлен на рис. 5.2. Восьмибитовое 
поле типа используется для присвоения значения тегу слрва 
стека данных при размещении в этой памяти очередной пере- 
менной. 

•> PSW (Program status word) —слово состояния программы. — Прим, 
перев. 
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Исходное содержимое памяти таблицы областей действия 
переменных (scope table memory) также устанавливается ком¬ 
пилятором или загрузчиком программ. Таблица содержит по 
одному элементу для каждого перехода на новый лексический 
уровень программы, т. е. по одному элементу для каждой про¬ 
цедуры, функции и блока BEGIN. Как показано на рис. 5.2, 
элемент таблицы областей действия переменных указывает 
элементы таблицы символических имен, связанные с данным 
лексическим уровнем, определяет число параметров, которые 
должны быть приняты, и сам уровень. 

Последним типом памяти учебной ПЛ-машины является 
стек указателей активизируемых сегментов программы (scope 
stack), используемый для хранения информации о процедурах, 
функциях и блоках BEGIN, к которым имело место обращение. 
Очередной элемент помещается в этот стек всякий раз, когда 
выполняется подобное обращение. 

Как показано на рис. 5.2, элемент, помещенный в этот стек, 
указывает на соответствующий элемент таблицы областей дей¬ 
ствия переменных и элемент данного стека для предыдущего 
лексического уровня программы, а также содержит величины, 
находящиеся в регистрах — указателях стековой памяти дан¬ 
ных, стека указателей сегментов программы и в регистре но¬ 
мера оператора исходной программы во время перехода на 
данный лексический уровень программы. 

Машина также содержит набор из 16 дисплей-регистров, 
используемых, как показано в гл. 4, для разрешения адресных 
ссылок на лексическом уровне. Дисплей-регистры пронумеро¬ 
ваны от 0 до 15; дисплей-регистр п содержит адрес элемента 
стека указателей активизируемых сегментов програм¬ 
мы, соответствующих активному лексическому уровню про¬ 
граммы п. 

Последний регистр — регистр номера оператора исходной 
программы — играет пассивную роль. Он используется для от¬ 
слеживания информации о выполняемом в данный момент опе¬ 
раторе исходной программы; таким образом, если будет обна¬ 
ружена ошибка, информация об этом может быть выдана про¬ 
граммисту на языке его исходной программы. Когда компиля¬ 
тор генерирует код, соответствующий, например, оператору ис¬ 
ходной программы с номером 17, то в первую очередь форми¬ 
руется этот номер, который загружается в данный регистр. 

УПРАЖНЕНИЯ 

5.1. Как используется 4-битовое поле типа слова стековой памяти дан¬ 
ных, если бит а имеет единичное значение (т. е. слово содержит указатель 
массива) ? 





УЧЕБНАЯ ПЛ-МАШИНА 173 


5.2. В какую память помещает свою выходную информацию компилятор 
и загрузчик программ? 

5.3. Содержимое какой памяти не изменяется во время выполнения прог¬ 
раммы? 

5.4. Как будет представлен в памяти массив строк символьных данных? 

5.5. Каково максимальное число лексических уровней в программе учеб¬ 
ной ПЛ-машины? 

5.6. Исходя из описания памяти различного назначения и регистров, оп¬ 
ределите, содержимое каких устройств изменяется при выполнении операто¬ 
ра CALL учебного языка ПЛ. 

5.7. Почему элемент стека указателей активизируемых сегментов програм¬ 
мы содержит явную ссылку на элемент ближайшего, более низкого лексиче¬ 
ского уровня? Не должен ли этот элемент всегда быть предыдущим словом, 
помещенным в стек? 
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ТРАНСЛЯЦИЯ И ВЫПОЛНЕНИЕ ПРОГРАММЫ 
УЧЕБНОЙ ПЛ-МАШИНЫ 

ПРИМЕР ПРОГРАММЫ 

Вместо того чтобы изучать архитектуру учебной ПЛ-машины 
путем последовательного рассмотрения ее команд, представ¬ 
ляется более целесообразным проанализировать примеры ком¬ 
пилирования и выполнения программ, написанных на одном и 
том же или различных языках высокого уровня. Вот почему в 
данной главе описываются процессы компилирования и транс¬ 
ляции двух программ на учебном языке ПЛ. Гл. 7 содержит 
представленные в традиционной форме спецификации команд, 
к которым читатель при желании может обращаться во время 
изучения материала данной главы. 

Учебная ПЛ-машина имеет ориентированный на работу со 
стеком набор команд. Первые 8 бит размещаются в поле кода 
операции. Большинство команд содержит только код операции, 
и, следовательно, их длина равна 8 бит. Некоторые команды 
описываются двумя 8-битовыми полями; назначение второго 
поля зависит от типа команды. Одна из команд (LNAME) име¬ 
ет длину 24 бит. 

Первый из рассматриваемых примеров — трансляция и вы¬ 
полнение простой процедуры (рис. 6.1). Предположим, что эта 
процедура — часть большой программы и находится на лекси¬ 
ческом уровне 2. В процедуре используются две переменные А 
и В; адресами этих переменных данного лексического уровня 
являются (2, 1) и (2, 2). Процедура также содержит константы 
1 и 3; этим константам назначены адреса (2,3) и (2,4). 

В результате компилирования данной процедуры создаются 
сегмент объектной программы в памяти сегментов программ и 
строк данных, четыре элемента в таблице символических имен 
и один элемент в таблице областей действия переменных. Эти 
элементы показаны на рис. 6.1; объектная программа опреде¬ 
ляется далее (будем полагать, что она записывается в памяти, 
начиная с адреса 446). 

Хотя теперь и следует приступить к анализу объектного ко¬ 
да, создаваемого в результате компилирования этой процеду- 
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ры, полезно рассмотреть ее выполнение. Предположим, что дан¬ 
ная процедура вызывается другой процедурой. Это означает, 
что последней командой, выполнявшейся в вызывающей про¬ 
цедуре, является команда ENTER. Команда ENTER указывает, 
где в стековой памяти должна находиться локальная область 
памяти для процедуры X, помещает соответствующие элементы 
в стек указателей сегментов программы и стек указателей ак¬ 
тивизируемых сегментов программы, обновляет содержимое 


ПО X: PROCEDURE; 

120 DECLARE A FIXED; 
130 DECLARE В FLOAT; 
140 В = 1; 

150 А = В + 3 ■ В, 

160 END; 


Элементы таблицы символических имен 

10 


13 


А 0 FIXED 

В 0 FLOAT _ 

_ 0 FIXED _1_ 

О FIXED 3 



Рис. 6.1. Первый пример программы учебной ПЛ-машины. 


дисплей-регистров. В результате состояние машины будет иметь 
вид, показанный на рис. 6.2. 

Теперь необходимо рассмотреть объектный код процедуры X. 
Для простоты представления объектный код записывается на 
гипотетическом языке ассемблера. 

Первой командой в любой процедуре должна быть команда 
SCOPEID; ее операндом — адрес элемента таблицы областей 
действия переменных, относящегося к данной процедуре. Во 
время выполнения команды SCOPEID не производится абсо¬ 
лютно никаких действий (т. е. эта команда аналогична команде 
НЕТ ОПЕРАЦИИ*)). Однако во время выполнения предшест¬ 
вующей ей команды ENTER машина обращается к команде 
SCOPEID для определения местоположения элемента стека 
указателей активизируемых сегментов; этот элемент в свою 
очередь определяет лексический уровень процедуры и соответ¬ 
ствующие входы таблицы символических имен. Следовательно, 
первой генерируется команда 

SCOPEID 8 

Следующим шагом является генерирование команд для опе¬ 
ратора 140. Первой из этих команд должна быть команда 

LINE 140 

ч Например, команде NOP языка ассемблера Системы 370 . — Прим, 
перев. 




по которой производится загрузка номера оператора в регистр 
номера оператора исходной программы. Для описания генери¬ 
рования остальных команд рассмотрим обратную польскую за¬ 
пись оператора: В1=. Такая запись показывает последователь- 


Стек указателей сегментов 

Стековая память данных программы 



ность команд, которые должны быть сформированы: загрузка 
адреса переменной В в стек, загрузка величины 1 в стек и за¬ 
пись значения переменной в память. Первой должна быть 
команда 

SNAME 2,2 

Операндом этой команды является адрес данного лексиче¬ 
ского уровня (адрес переменной В). Команда формирует 
дескриптор косвенного адреса и загружает его в стек. Дескрип¬ 
тор косвенного адреса является не полностью определенным ад¬ 
ресом лексического уровня. Представление дескриптора длиной 
32 бит включает 12-битовый адрес элемента стека указателей 
активизируемых сегментов программы и 20-битовое смещение 
относительно исходного содержимого регистра — указателя 
стековой памяти данных. Формирование дескриптора косвенно¬ 
го адреса производится очень просто. Выполняя команду 
SNAME х, у, машина создает дескриптор косвенного адреса, 
значение первых 12 бит которого равно величине х, находящей- 
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ся в дисплей-регистре, а остальные 20 бит — величине у. Следо¬ 
вательно, команда формирует дескриптор косвенного адреса, 
содержащий величину 17,2, в слове стековой памяти данных с 
адресом 101. 

Следующий шаг — загрузка в стек величины 1. Это дейст¬ 
вие выполняют команды 

SNAME 2,3 

EVAL 

Первая из этих команд формирует дескриптор косвенного 
адреса, содержащий величину 17,3, в слове стековой памяти 
данных с адресом 102 (регистр — указатель стековой памяти 
данных теперь указывает на слово с адресом 102). По команде 
EVAL на место дескриптора косвенного адреса, находящегося 
на вершине стека, помещается содержимое слова, адресуемого 
этим дескриптором. Чтобы выполнить такую операцию, машина 
обращается к слову стека указателей активизируемых сегмен¬ 
тов с адресом 17, извлекает записанное в этом слове значение 
указателя стековой памяти данных (96), добавляет к нему 3 
(получая 99) и пересылает содержимое слова стековой памяти 
данных с этим адресом (константу 1) на вершину стека. Сле¬ 
довательно, слово стековой памяти данных с адресом 102 со¬ 
держит теперь копию слова с адресом 99. 

Затем генерируется команда 

STORE 

Эта команда имеет дело с двумя словами, находящимися на 
вершине стека. Предполагается, что второе слово представляет 
собой дескриптор — в данном случае дескриптор косвенного 
адреса переменной В. Команда копирует содержимое слова, 
находящегося на вершине стека, в слово, указываемое де¬ 
скриптором, а затем удаляет второе слово. Следовательно, сло¬ 
во с адресом 98 (переменная В) теперь содержит величину 1, 
а бит ее метки, указывающий на неопределенное содержимое 
слова, равен нулю, т. е. сброшен. Заметим, что данные типа 
FIXED записываются в слово памяти, для которого установлен 
тип данных FLOAT; машина распознает эту ситуацию и выпол¬ 
няет требуемое преобразование данных в форму с плавающей 
точкой. 

Теперь оператор В=1 выполнен, но указатель стековой па¬ 
мяти данных имеет значение 101 (величина 1 все еще находит¬ 
ся в стеке). Производится очистка стека с помощью команды 
POP 

которая удаляет слово, находящееся на вершине стека (т. е. 
вычитает 1 из указателя стековой памяти данных). 

Объектный код оператора исходной программы с номером 


12-283 
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150 генерируется аналогичным образом. Обратная польская за¬ 
пись оператора 150 имеет вид: АВЗВ* + = ; а генерируемый код 


LINE 

150 


SNAME 

2,1 

дескриптор косвенного адреса перемен¬ 
ной А,... 

SNAME 

2,2 

дескриптор косвенного адреса перемен¬ 
ной В, дескриптор косвенного адреса пере¬ 
менной А, ... 

EVAL 


1, дескриптор косвенного адреса перемен¬ 
ной А,... 

SNAME 2,4 

дескриптор косвенного адреса константы 
3,1, дескриптор косвенного адреса пере¬ 
менной А,... 

EVAL 


3,1, дескриптор косвенного адреса пере¬ 
менной А,... 

SNAME 

2,2 

дескриптор косвенного адреса переменной 
В, 3,1, дескриптор косвенного адреса пере¬ 
менной А, ... 

EVAL 


1,3,1, дескриптор косвенного адреса пере¬ 
менной А,... 

MUL 


3,1, дескриптор косвенного адреса перемен¬ 
ной А,... 

ADD 


4, дескриптор косвенного адреса перемен¬ 
ной А,... 

STORE 


4,... 

POP 



Справа 

от записи каждой команды показано получаемое в 


результате ее выполнения содержимое слов стековой памяти 
данных, начиная с адреса 101 и выше. Наряду с выполнением 
своих основных функций команда EVAL проверяет также, яв¬ 
ляется ли операнд операции определенной величиной. Напри¬ 
мер, если бы переменная В представляла собой неопределен¬ 
ную величину, то при выполнении первой команды EVAL про¬ 
изошло бы программное прерывание. Арифметические команды 
MUL и ADD выполняют свои операции над содержимым двух 
слов, находящихся на вершине стека, затем удаляют эти слова 
и загружают результат в стек. Если операнды этих команд 
представляют собой числовые данные различного типа (как это 
имеет место при выполнении команды MUL), то во время вы¬ 
полнения команды производится автоматическое преобразова¬ 
ние формы представления данных. Оставшаяся часть генери¬ 
руемого объектного кода имеет вид 
LINE 160 
END 8 
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По команде END производится возврат управления в вы¬ 
зывающую процедуру; при этом уничтожаются локальная па¬ 
мять данных в стековой памяти данных, элементы, находящие¬ 
ся на вершине стека указателей сегментов программы и стека 
указателей активизируемых сегментов, и обновляется содержи¬ 
мое дисплей-регистров. В данном случае при выполнении 
команды END в регистре — указателе стековой памяти данных 
установится значение, равное 96, в регистре — указателе стека 
указателей сегментов программы — значение 60, в регистре — 
указателе стека указателей активизируемых сегментов — значе» 
ние 16 и в дисплей-регистре 2 — значение 0. 


СЕГМЕНТЫ ПРОГРАММЫ 

ДЛЯ ОПЕРАТОРОВ IF И ЦИКЛОВ DO 

Одной из необычных характеристик учебной ПЛ-машины 
является отсутствие команды перехода. Имеющаяся в этой ма¬ 
шине команда GO ТО соответствует оператору GO ТО учебно¬ 
го языка ПЛ. С помощью команды GO ТО управление переда¬ 
ется по адресу, задаваемому дескриптором метки-константы 
или метки-переменной. 

Отсутствие команды передачи управления ставит вопрос о 
том, как должен выглядеть объектный код программы для опе¬ 
раторов IF и циклов DO. Разработчики архитектуры машины 
полагали, что оператор IFTHENELSE можно рассматривать как 
условный вызов подпрограммы. Если условие, задаваемое опе¬ 
ратором IF, выполняется, то вызывается код, соответствующий 
предложению THEN, если не выполняется, то действует код, 
соответствующий предложению ELSE. В обоих случаях управ¬ 
ление возвращается оператору, следующему за оператором IF. 
Подобным же образом цикл DO можно рассматривать как вы¬ 
зов тела цикла, после чего производится возврат к выполнению 
оператора, следующего за циклом DO. В свою очередь тело 
цикла считается состоящим из повторяющихся проверок усло¬ 
вия выхода из цикла DO, за которыми следует вызов кода, ука¬ 
занного в цикле. 

Производимые действия лучше всего понять на каком-ни¬ 
будь примере. Предположим, что к процедуре X, показанной на 
рис. 6.1, добавлен оператор 

155 IF (А = 1) THEN В = 3; 

ELSE А=3; 

Вместо генерирования одного сегмента программы компиля¬ 
тор теперь сформирует три сегмента. Двумя новыми сегмента¬ 
ми являются следующие: 


12 * 
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SNAME 2,2 
SNAME 2,4 
EVAL 
STORE 
POP 


SNAME 2,1 
SNAME 2,4 
EVAL 
STORE 
POP 


Первым шагом при выполнении оператора 155 является про¬ 
верка условия, указанного в операторе IF; генерируемый код 
начинается со следующих команд: 


LINE 

155 

SNAME 

2,1 

EVAL 


SNAME 

2,3 

EVAL 


EQ 


Команда EQ сравнивает содержимое двух слов, находящих- 


ся на вершине стека, с целью выяснения, равны ли они (при 
этом, если необходимо, то выполняются требуемые преобразо¬ 
вания формы представления данных), и помещает на их место 
на вершину стека логическую переменную. Теперь, если предва¬ 
рительно был подготовлен одномерный массив из двух элемен¬ 
тов, представляющих дескрипторы двух сегментов программы, 
то может быть сгенерирована команда SUBS (subscript), в ко¬ 
торой используется значение логической переменной для выбо¬ 
ра одного из дескрипторов сегментов программы. После этого 
с помощью команды CALL вызывается надлежащий сегмент 
программы. Имя CALL (ВЫЗОВ) для данной команды выбра¬ 
но неудачно, поскольку по команде CALL элемент только по¬ 
мещается в стек сегментов программы и производится передача 
управления в этот сегмент. При выполнении команды не проис¬ 
ходит передачи параметров или изменения лексического уров¬ 
ня. Командой машинного уровня, соответствующей оператору 
CALL учебного языка ПЛ, является команда ENTER. 

Для оператора 155 описанные выше команды генерируются 
после команды EQ: 

SNAME 2,5 Формирование дескриптора косвенного 
адреса сегмента программы 

SWAP Обмен содержимым между двумя словами, 

находящимися в верхней части стека 

SUBS 1 Помещение дескриптора элемента массива 
на вершину стека (регистр — указатель сте¬ 
ковой памяти данных содержит теперь ве¬ 
личину 101) 
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EVAL Помещение на место указанного выше де¬ 

скриптора значения элемента массива 
(дескриптора сегмента программы) 

CALL Переход к выполнению сегмента програм¬ 

мы; по достижении конца сегмента возврат 
управления в данную точку программы 
К сожалению, приведенный выше пример не содержит всех 
команд, генерируемых компилятором. В таблицу символиче- 



Рис. 6.3. Результаты работы транслятора для модифицированной 
процедуры X. 


ских имен необходимо поместить соответствующие элементы. 
Поскольку для массивов память автоматически не распреде- 
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ляется, то должны быть добавлены команды ALLOCATE и 
FREE для выделения и освобождения памяти массива. Так как 
массив должен быть инициализирован, необходимо сформиро¬ 
вать еще два элемента (дескрипторы сегментов программы) в 
таблице символических имен и должны быть сгенерированы 
команды инициализации массива. Полный листинг работы ком¬ 
пилятора для процедуры X, в которую добавлен оператор IF, 
показан на рис. 6.3. 

Чтобы понять, во что обходится подобная реализация опера¬ 
торов, предположим, что к набору команд учебной ПЛ-машины 
добавляют две новые команды: BRANCH (ПЕРЕХОД) и 
BRANCH FALSE (ПЕРЕХОД, ЕСЛИ ЛОЖНО). Обе команды 
имеют длину 16 бит; следующие за кодом операции 8 бит пред¬ 
ставляют собой величину со знаком, добавляемую к содержимо¬ 
му счетчика команд. Для команды BRANCH FALSE эта вели¬ 
чина добавляется, если только логическая величина, находя¬ 
щаяся на вершине стека, имеет значение FALSE. По команде 
BRANCH FALSE из стека удаляется слово, находящееся на 
его вершине. С учетом этих изменений объектная программа, 
приведенная на рис. 6.3, может быть записана в 'Следующем 
виде: 


SCOPEID 

8 

STORE 


SNAME 

2,3 

LINE 

140 

POP 


EVAL 


SNAME 

2,2 

LINE 

150 

EQ 


SNAME 

2,3 

SNAME 

2,1 

BRANCHF 

11 

SNAME 

2,2 

SNAME 

2,2 

POP 


EVAL 

EVAL 

BRANCH 

9 

MUL 


SNAME 

2,4 

SNAME 

2,1 

ADD 


EVAL 


SNAME 

2,4 

SNAME 

2,2 

STORE 


EVAL 

SNAME 

2,4 

POP 


STORE 


EVAL 

LINE 

155 

POP 


STORE 


SNAME 

2,1 

LINE 

160 

EVAL 


EVAL 

END 

8 


Описанные выше незначительные изменения в наборе команд 
уменьшают количество генерируемых команд программы с 67 
до 39 и улучшают временные характеристики системы, посколь¬ 
ку из программы исключаются команды SUBS, ALLOC, FREE 
и CALL, выполнение которых занимает значительное время. 

Однако отсутствие традиционных команд перехода делает 
реализацию циклов DO-WHILE и итеративных циклов DO 
еще более сложной. Для выполнения циклов DO требуются 
два уровня вызова сегментов; для этой цели предусмотрено не¬ 
сколько команд: CYCLE, DOTEST, DOINCR (см. гл. 7). 
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Приведенные выше критические замечания относительно ре¬ 
ализации операторов IF и DO в учебной ПЛ-машине не сле¬ 
дует воспринимать как критику всей машины, поскольку послед¬ 
няя используется только как средство для изучения некоторых 
новых подходов к построению архитектуры ЭВМ. Однако мож¬ 
но сделать вывод, что целью выбора варианта построения архи¬ 
тектуры является достижение точного и эффективного выполне¬ 
ния машиной программ, написанных на языках высокого уров¬ 
ня. Кроме того, следует признать неоправданным стремление 
разработчиков архитектуры машины исключить из набора 
команд команду перехода или свести к минимуму использова¬ 
ние оператора GO ТО. 

ПРИМЕР ВЫЗОВА ПОДПРОГРАММЫ 

Поскольку существенная часть архитектуры связана с автома¬ 
тическим управлением подпрограммами и операциями над мас¬ 
сивами данных, целесообразно проанализировать пример, в ко¬ 
тором раскрываются соответствующие возможности архитекту¬ 
ры. Рассмотрим следующую программу, написанную на учеб¬ 
ном языке ПЛ: 

1 XYZ: PROCEDURE; 

2 DECLARE А(*) FLOAT; 

3 DECLARE (В,С) FIXED; 

4 В=4; 

5 ALLOCATE А(1 : В); 

6 А = 1; 

7 С=В+В*В; 

8 CALL ZZZ(B); 

9 А(В)=С; 

10 ZZZ: PROCEDURE (М); 

11 DECLARE М FIXED; 

12 С=МфМ; 

13 END; 

14 END; 

На рис. 6.4 показаны два сегмента программы, сгенериро¬ 
ванные компилятором. Для удобства ссылок машинные коман¬ 
ды пронумерованы. Предположим, что первый сегмент распо¬ 
лагается в памяти сегментов программ и строк данных, начи¬ 
ная с адреса 200, а второй — с адреса 800. На рис. 6.5 представ¬ 
лена остальная информация, формируемая в результате работы 
компилятора, а рис. 6.6 демонстрирует состояние машины при 
входе в сегмент XYZ. 

Команды 1—8 понятны без пояснений и подобны командам, 
содержащимся в предыдущем примере. Команды 9—14 предна¬ 
значены для распределения памяти для массива А. По команде 
ALLOC на вершину стека помещается дескриптор косвенного 
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адреса указателя массива, за которым следуют минимальные и 
максимальные граничные значения индексов. Заметим, что 
оператор 6 исходной программы выполняет операцию над мас¬ 
сивом: все элементы массива А устанавливаются равными 1. 
Эта операция реализуется с помощью команд 16—20. При вы¬ 
полнении команды STORE выясняется, что в массив записи- 

Сегмент XYZ Сегмент 22Z _ 


3 SNAME 0,2 

4 ЭКАЯЕ 0,4 

5 EVAL 

6 STORE 

8 LIRE 5 

9 SHARE 0,2 

10 EVAL 

11 SNAKE 0,5 

12 EVAL 

13 SHAKE 0,1 

14 ALLOC 1 

15 LIRE 6. 

16 SNAKE 0,1 

17 SNAKE 0,5 

18 EVAL 

19 STORE 

20 POP 

21 LINE 7 

22 SNAKE 0,3 

23 SNAKE 0,2 

24 EVAL 

25 SNAKE 0,2 

26 EVAL 


28 EVAL 

29 KOL 

30 ADD 
31. STORE 

32 POP 

33 LINE 8 

34 SNAKE 0,2 

35 SNAKE 0,6 

36 ENTER 1 

37 POP 

39 LINE 9 

40 SHAKE 0,1 

41 SNAKE 0,2 

42 EVAL 

43 SUBS 1 

44 SNAKE 0,3 

45 EVAL 

46 STORE 

47 POP 

48 LINE 14 

49 HALT 


50 SCOPEID 2 

51 LINS 12 



57 ADD 

58 STORE 

59 POP 

60 LINE 13 

61 UNDEF 

62 END 2 


Рис. 6.4. Объектный код 
для процедур XYZ 


вается скалярная величина. Следовательно, эта скалярная ве¬ 
личина помещается в каждый элемент массива. 

Команды 34—38 генерируются в результате компилирова¬ 
ния оператора CALL. Операнд команды ENTER определяет 
количество аргументов вызова процедуры (фактических пара¬ 
метров). Дескрипторы фактических параметров и дескриптор 
сегмента программы должны находиться в стеке. При реализа¬ 
ции команды ENTER проверяется соответствие количества фак¬ 
тических параметров процедуры количеству ее формальных па¬ 
раметров, изымается из стека указатель дескриптора сегмента 
программы, распределяется память в стековой памяти данных 
для вызываемой процедуры — в данном случае выделяется одно 
слово памяти для переменной М. Кроме того, производится 
присвоение значений дескрипторов косвенных адресов факти¬ 
ческих параметров формальным параметрам процедуры в каче¬ 
стве начальных значений, соответствующие элементы помеща¬ 
ются в стек указателей сегментов программы и стек указателей 
активизируемых сегментов и обновляется содержимое дисплей- 
регистров. В результате этого начинается выполнение процеду¬ 
ры ZZZ. 
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При выполнении команды 54 дескриптор косвенного адреса, 
находящийся на вершине стека (помещенный туда коман¬ 
дой 53), указывает на другой дескриптор косвенного адреса 
(слово, представляющее переменную М в слове 8 стековой па¬ 
мяти данных, которому было присвоено начальное значение как 


Элементы таблицы символических имен 



Элементы таблицы областей 
действия переменных 


Л » 


Рис. 6.5. Таблица 
символических имен 
и таблица областей действия 
переменных для процедур 
XYZ и ZZZ. 



Рис. 6.6. Состояние машины при входе в процедуру XYZ. 


параметру процедуры), который в свою очередь ссылается на 
переменную В. Реализация описываемых действий не вызывает 
затруднений, поскольку команда EVAL по определению способ¬ 
на «отслеживать» цепочку дескрипторов. Благодаря этому ве¬ 
личина, находящаяся в конце цепочки, записывается на верши¬ 
ну стека. 

Функции команды END почти полностью противоположны 
функциям команды ENTER. Однако, поскольку команда END 
используется также и для возврата из процедур-функций (о ре¬ 
зультате выполнения которых в вызывающую программу долж- 
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но передаваться определенное значение), предполагается, что 
на вершине стека находится вычисленное значение функции. 
После выполнения команды END локальная память для этой 
процедуры удаляется из стека и на вершину стека помещается 
возвращаемая величина. Так как вызов процедуры не сопро¬ 
вождается формированием такой величины, то генерируется 
команда UNDEF, -по которой в стек загружается слово неопре¬ 
деленной величины. По команде 37 в вызывающем сегменте 
программы эта величина изымается из стека. 

Команды 40—47 соответствуют оператору А(В)=С. При вы¬ 
полнении команд 40—43 дескриптор элемента массива поме¬ 
щается на вершину стека. Если значение переменной В оказы¬ 
вается за пределами граничных значений индекса массива, то 
при выполнении команды SUBS произойдет программное пре¬ 
рывание. Команда STORE производит запись значения перемен¬ 
ной С (автоматически преобразуемое в форму с плавающей 
точкой) в элемент, адресуемый дескриптором элемента мас¬ 
сива. 


ДОСТОИНСТВА УЧЕБНОЙ пл-машины 


Чтобы оценить достоинства учебной ПЛ-машины по сравнению 
с традиционной ЭВМ, можно сравнить написанную на учебном 
языке ПЛ программу, приведенную в предыдущем разделе, 
с эквивалентной программой на языке ПЛ/1, компилируемой в 
Системе 370. Ниже дается текст этой программы: 


(SUBSCRIPTRANGE) : XYZ: PROCEDURE; 
DECLARE А(*) FLOAT BINARY (21) CTL; 
DECLARE (B.C) FIXED BINARY (31); 
B=4; 

ALLOCATE A(1 : B); 

C=B+B*B; 

CALL ZZZ(B); 

A(B)=C; 

ZZZ: PROCEDURE (M); 

DECLARE M FIXED BINARY (31); 
C=M+M; 

END: 

END 


Программа, написанная на учебном языке ПЛ, состоит из 
62 выполняемых команд, которые занимают в ПЛ-машине 
96 байт памяти. Принимая во внимание таблицу символических 
имен и таблицу областей действия переменных, общий размер 
программы составляет 369 байт. При использовании в Системе 
370 оптимизирующего транслятора языка ПЛ/1 фирмы IBM 
объектный код программы на языке ПЛ/1 занимает 564 байт 
памяти, а количество выполняемых команд равно 303. С учетом 
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выполнения подпрограмм суммарный объем памяти для про¬ 
граммы в Системе 370 составляет 5912 байт. 

Не вполне правильно сопоставлять 62 команды с 303 коман¬ 
дами, так как в действительности при выполнении программы 
Системой 370 количество команд будет намного больше. Одна¬ 
ко непосредственное сравнение количества команд не имеет су¬ 
щественного значения. Компилятор Системы 370 обеспечивает 
эффективные средства вызова подпрограмм и возврата из них, 
однако при этом в начале программы приходится выполнять 
большое число команд, выделяющих память для этих средств. 
Поскольку указанные команды выполняются за время прогона 
программы только один раз, при сравнении их можно не прини¬ 
мать во внимание. 

Можно оспаривать утверждение о том, что проводимое срав¬ 
нение необоснованно «смещено» не в пользу языка ПЛ/1, по¬ 
скольку все массивы программы на учебном языке ПЛ должны 
размещаться динамически, а использование в приведенной выше 
программе на языке ПЛ/1 управляемой памяти 1 ) и оператора 
ALLOCATE для массива А не является обязательным. Но если 
исключить из программы оператор ALLOCATE, удалить мас¬ 
сив А из управляемой памяти и тем самым сделать недееспо¬ 
собной процедуру SUBSCRIPTRANGE, объектный код, гене¬ 
рируемый компилятором Системы 370, будет занимать 360 байт 
памяти, число выполняемых команд станет равным 112, а сум¬ 
марный размер программы составит 5496 байт. 

С точки зрения идей, изложенных в гл. 4, в учебной ПЛ-ма- 
шине реализован принцип теговой памяти, которая использует¬ 
ся для выполнения требуемых преобразований формы представ¬ 
ления данных. Эта машина предоставляет пользователю набор 
команд, инвариантных к типу обрабатываемых данных, и рас¬ 
полагает средствами обнаружения в программе ошибок не¬ 
скольких типов. Машине «известно» понятие «массив данных»; 
в ней определены операции над массивами, индексирование 
элементов массивов; машина способна обнаруживать некор¬ 
ректно заданные индексы. Машина также располагает средст¬ 
вами управления подпрограммами, ориентированными на язык 
программирования блочной структуры; при этом машина спо¬ 
собна обнаруживать несоответствие между типами аргументов 
в обращении к процедуре и типами параметров вызываемой 
процедуры. 

Как следует из приведенного выше примера, параметр S 
учебной ПЛ-машины превосходит по величине подобные пара¬ 
метры для машин с традиционной архитектурой (при условии. 


■> То есть указание атрибута CTL в операторе DECLARE. — Прим, пе- 

рев. 
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что сравниваются программы и языки, для которых проектиро¬ 
валась исследуемая машина). 

Однако параметр М, оценивающий в битах количество пере¬ 
даваемой информации, для этой машины оказывается ненамно¬ 
го выше, главным образом вследствие интенсивного обращения 
к памяти, занимаемой стеком операндов. 

Объективно оценивая учебную ПЛ-машину, укажем несколь¬ 
ко причин, по которым ее архитектуру (в том виде, как она 
представлена в настоящее время) следует признать непрактич¬ 
ной и даже нежелательной. Во-первых, эта машина представ¬ 
ляет собой только модель вычислительного процесса, так что 
вопросы, связанные с операционной системой и организацией 
ввода-вывода, для нее не решены. Во-вторых, ее архитектура, 
ориентированная на язык программирования, слишком сильно 
«привязана» именно к учебному языку ПЛ. Например, компи¬ 
лирование программ, написанных на учебном языке ПЛ, произ¬ 
водится непосредственно, однако компилирование программ на 
других языках таким же образом выполняться не может. Даже 
программы, написанные на языке ПЛ/1, наиболее близком к 
учебному языку ПЛ, на данной машине компилировать нельзя, 
поскольку многие конструкции языка ПЛ/1 (такие, как струк¬ 
туры, базированные переменные) не «поддерживаются» этой 
машиной. Кроме того, архитектура машины не позволяет ис¬ 
пользовать независимо компилируемые процедуры. 

Менее существенным являются громоздкость и неэффектив¬ 
ность описанного выше способа реализации операторов IF и 
DO с точки зрения как сложности компилирования, так и эф¬ 
фективности выполнения. 

В этой связи можно заключить, что не следует вводить в архи¬ 
тектуру структуры, непосредственно отображающие все конст¬ 
рукции языка, особенно когда эти конструкции имеют преиму¬ 
щественно синтаксическую, а не семантическую природу. Не¬ 
смотря на использование теговой памяти и набора команд, 
инвариантного к тилу обрабатываемых данных, для машины 
свойственна избыточность памяти. Например, каждый элемент 
массива имеет идентичный, за исключением бита — признака 
неопределенной величины, 7-битовый тег, и поэтому представле¬ 
ние логических величин является крайне неэффективным 1 ). 

УПРАЖНЕНИЯ 

6.1. Какая информация находится в стеке данных перед выполнением 
команды ALLOC первого сегмента программы, приведенной на рис. 6.3? 

6.2. Каково назначение восьми команд, следующих за командой ALLOC 
первого сегмента программы, приведенной на рис. 6.3? 


11 Логическая переменная, принимающая значение 0 или 1, занимает 
полное слово памяти (39 бит). — Прим, перев. 
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6.3. Каким образом команда ENTER определяет вход в таблицу обла¬ 
стей действия переменных (т. е. первый элемент таблицы, относящийся к дан¬ 
ному сегменту программы) при вызове сегмента программы? 

6.4. Как команда ENTER определяет соответствие количества фактиче¬ 
ских параметров процедуры количеству формальных параметров? 

6.5. Каково назначение двух команд POP (команд с номерами 37 и 38) 
программы, приведенной на рис. 6.4? 

6.6. Каким образом определяются элементы таблицы символических имен» 
представляющие собой формальные параметры, при инициализации парамет¬ 
ров, производимой во время выполнения команды ENTER? 

6.7. Для лучшего понимания архитектуры ЭВМ полезно мысленно выпол¬ 
нить компилирование исходной программы. Придумайте небольшую програм¬ 
му на учебном языке ПЛ и выполните в уме ее компилирование на учебной 
ПЛ-машине. (Все команды ПЛ-машины определены в гл. 7.) 



ГЛАВА 7 

НАБОР КОМАНД УЧЕБНОЙ ПЛ-МАШИНЫ 

В этой главе приводится сводный перечень с соответствующей 
спецификацией команд ПЛ-машины. Спецификация команд 
заимствована из исходного описания машинного языка. Дей¬ 
ствия, выполняемые этой машиной при обнаружении ошибок в 
программе, не указываются, поскольку они были опущены и в 
первоначальном описании. 

Для облегчения изучения команды разделены на пять групп. 
Команды доступа к данным и управления адресацией исполь¬ 
зуются для выборки и записи адресов и величин данных в сте¬ 
ковой памяти данных. Команды обработки данных выполняют 
арифметические и логические операции, а также операции над 
строками данных. Команды управления предназначены для уп¬ 
равления последовательностью выполнения команд программы 
и реализации операторов IF и DO. Команды работы с процеду¬ 
рами используются для управления процедурами, процедурами- 
функциями и блоками BEGIN. В последнюю группу входят 
команды управления памятью массивов, с помощью которых 
распределяется память для массивов. 

При описании команд показано их воздействие на содержи¬ 
мое стековой памяти данных, т. е. указаны величины, находя¬ 
щиеся в стеке до и после выполнения команд. При описании 
содержимого стека предполагается его горизонтальное распо¬ 
ложение 1 *: крайнее слева символическое имя обозначает инфор¬ 
мацию, расположенную на вершине стека, а символическое имя 
X представляет содержимое нижней части стека, не участвую¬ 
щей в операциях рассматриваемой команды. 

В тех случаях, когда при описании команды указывается, 
что она использует дескриптор косвенного адреса, расположен¬ 
ный в стеке, соответствующее слово стека может содержать 

■> Иначе говоря, содержимое стека представлено строкой символических 
имен, разделяемых запятыми: одно имя — одно слово стека. — Прим. ред. 
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дескриптор косвенного адреса некоторого операнда (одноуров¬ 
невая косвенная адресация), дискриптор косвенного адреса 
другого дескриптора косвенного адреса и т. д., указывая, нако¬ 
нец, адрес некоторого операнда (многоуровневая косвенная ад¬ 
ресация) или непосредственно операнд. 

КОМАНДЫ ДОСТУПА К ДАННЫМ 
И УПРАВЛЕНИЯ АДРЕСАЦИЕЙ 

Имя команды. SNAME 
Длина команды. 16 бит. 

Выполняемая операция. Загрузка в стек дескриптора косвенно¬ 
го адреса адресуемого слова. 

Содержимое информационного поля команды. Адрес лексиче¬ 
ского уровня. Первые 4 бит —номер лексического уровня, по¬ 
следние 4 бит — значение индекса. 

Исходное содержимое стека. X 
Конечное еодержимое стека. VAR, X 

Операнды. VAR — дескриптор косвенного адреса, формируемый 
из адреса лексического уровня. Если адресуемое слово содер¬ 
жит дескриптор косвенного адреса, то VAR принимает его зна¬ 
чение. 

Имя команды. LNAME 
Длина команды. 24 бит. 

Выполняемая операция. Загрузка в стек дескриптора косвенно¬ 
го адреса адресуемого слова. 

Содержимое информационного поля команды. Адрес лексиче¬ 
ского уровня. Первые 4 бит представляют собой номер лексиче¬ 
ского уровня, последние 12 бит —значение индекса. 

Исходное еодержимое стека. X 
Конечное еодержимое стека. VAR, X 

Операнды. VAR — дескриптор косвенного адреса, формируемый 
из адреса лексического уровня. Если адресуемое слово содер¬ 
жит дескриптор косвенного адреса, то VAR принимает его зна¬ 
чение. 

Имя команды. EVAL 
Длина команды. 8 бит. 

Выполняемая операция. Замена дескриптора, находящегося на 
вершине стека, содержимым адресуемого слова. 

Исходное содержимое стека. VAR1, X 
Конечное содержимое стека. VAR2, X 

Операнды. Если переменная VAR1 не является дескриптором 
косвенного адреса или дескриптором элемента массива, то 
VAR2=VAR1, иначе значение VAR2 равно содержимому адре- 
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суемого слова. Переменная VAR1 не может быть дескриптором 
косвенного адреса или дескриптором элемента массива; для 
указания местоположения требуемых данных используется 
цепочка дескрипторов, ссылающихся друг на друга. Если зна¬ 
чение переменной VAR2 не определено, то выдается сообщение 
об ошибке. 

Имя команды. STORE 
Длина команды. 8 бит. 

Выполняемая операция. Запись содержимого слова, находяще¬ 
гося на вершине стека, в память по адресу, указываемому вто¬ 
рым словом стека. 

Исходное содержимое стека. VAR1, VAR2, X 
Конечное содержимое стека. VAR1, X 

Операнды. Переменная VAR2 — дескриптор косвенного адреса, 
дескриптор элемента массива или указатель массива. Перемен¬ 
ная VAR1 записывается в адресуемую область памяти. Если 
VAR1 —указатель массива, а адресуемая ячейка памяти содер¬ 
жит указатель массива, то второй массив заполняется содер¬ 
жимым первого. Если переменная VAR1 не является указате¬ 
лем массива, то ее значение записывается во все элементы вто¬ 
рого массива. Если тип переменной VAR1 отличен от типа дан¬ 
ных, указываемого тегом адресуемой области памяти, то авто¬ 
матически выполняется требуемое преобразование данных. 
Примечание. Правила преобразования не были точно определе¬ 
ны в первоначальном описании, но, по всей видимости, они те 
же, что и соответствующие правила языка ПЛ/1. 

Имя команды. SUBS 
Длина команды. 16 бит. 

Выполняемая операция. Формирование дескриптора элемента 
адресуемого массива или части массива (секции массива). 
Содержимое информационного поля команды. N — число ин¬ 
дексов. 

Исходное содержимое стека. VAR1, ..., VARN, VARP, X 
Конечное содержимое стека. VAR Q, X 

Операнды. VAR1 — VARN — переменные, каждая из которых 
является индексом элемента массива и может быть представле¬ 
на логической величиной, числом с фиксированной или плаваю¬ 
щей точкой, либо знаком звездочки. При использовании логи¬ 
ческих величин или чисел с плавающей точкой осуществляется 
их преобразование в числа с фиксированной точкой. Перемен¬ 
ная VARP — это указатель массива или дескриптор косвенного 
адреса (либо начало цепочки дескрипторов косвенного адреса) 
указателя массива. 

Если ни один из индексов не задан в виде звездочки, то пере- 
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менная VARQ — дескриптор адресуемого элемента массива. Ес¬ 
ли для задания одного или нескольких индексов использована 
звездочка, то в памяти дескрипторов массивов формируется 
дескриптор определенной части массива, a VARQ будет пред¬ 
ставлять собой указатель этого дескриптора. Если значения 
индексов оказываются за их пределами для соответствующего 
массива или N не равно размерности массива, выдается сооб¬ 
щение об ошибке. 

Имя команды. POP 
Длина команды. 8 бит. 

Выполняемая операция. Удаление слова, находящегося на вер¬ 
шине стека. 

Исходное содержимое стека. VAR, X 
Конечное содержимое стека. X 

Имя команды. SWAP 
Длина команды. 8 бит. 

Выполняемая операция. Обмен содержимым двух слов, нахо¬ 
дящихся в верхней части стека. 

Исходное содержимое стека. VAR1, VAR2, X 
Конечное содержимое стека. VAR2, VAR1, X 

Имя команды. UNDEF 
Длина команды. 8 бит. 

Выполняемая операция. Загрузка в стек слова, содержащего 
неопределенную величину. 

Исходное содержимое стека. X 
Конечное содержимое стека. VAR, X 

Операнды. Значение VAR не определено (бит и тега слова ра¬ 
вен 1). 

КОМАНДЫ ОБРАБОТКИ ДАННЫХ 

Имя команды. ADD, SUB, MUL, DIV, PWR 
Длина команды. 8 бит. 

Выполняемая операция. Выполнение арифметических операций 
над содержимым двух слов, находящихся в верхней части стека. 
Исходное содержимое стека. VAR1, VAR2, X 
Конечное содержимое стека. VAR3, X 

Операнды. Значения переменных VAR1 и VAR2 должны быть 
числами с фиксированной или плавающей точкой. Если одна 
переменная представлена в форме с плавающей точкой, то вто¬ 
рая автоматически преобразуется в такую же форму. Операция 
выполняется согласно следующему правилу: 
VAR3-VAR2.op.VARl 

13-283 
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где op —код операции. Если переменные VAR1 и VAR2 — ука¬ 
затели массивов, то операция выполняется над соответствую¬ 
щими элементами этих массивов. В результате создается но¬ 
вый массив, причем переменная VAR3 служит его указателем. 
Если переменная VAR1(VAR2) —указатель некоторого масси¬ 
ва, а переменная VAR2(VAR1) —скалярная величина, то над 
каждым элементом массива выполняется арифметическая опе¬ 
рация как над скаляром. В результате создается новый массив 
с переменной VAR3 в качестве указателя этого массива. 
Замечание. Преобразование формата данных исходных операн¬ 
дов не влияет на форму представления операнда в памяти. Это 
преобразование производится только во время выполнения 
команды. 

Имя команды. CAT 
Длина команды. 8 бит. 

Выполняемая операция. Формирование строки символов путем 
конкатенации (сцепления) двух строк. 

Исходное содержимое стека. VAR1, VAR2, X 
Конечное содержимое стека. VAR3, X 

Операнды. Переменные VAR1 и VAR2 — дескрипторы логиче¬ 
ских величин, чисел с фиксированной или плавающей точкой 
либо строки символов. Если указанные переменные не являют¬ 
ся дескрипторами строк символов, то адресуемые данные пре¬ 
образуются в строки символов. В памяти сегментов программ 
и строк данных формируется новая строка символов, состоя¬ 
щая из строки, задаваемой переменной VAR2, за которой сле¬ 
дует строка, задаваемая переменной VAR1. Переменная 
VAR3 — дескриптор строки символов. Как и в предыдущих 
командах, если переменная VAR1 и (или) VAR2 являются 
указателями массивов, то операция выполняется над элемента¬ 
ми массивов, причем переменная VAR3 становится указателем 
нового массива. 

Имя команды. LT, GT, LE, GE, EQ, NE 
Длина команды. 8 бит. 

Выполняемая операция. Выполнение операций сравнения над 
содержимым двух слов, находящихся в верхней части стека. 
Исходное содержимое стека. VAR1, VAR2, X 
Конечное содержимое стека. VAR3, X 

Операнды. Сравнение выполняется согласно следующему пра¬ 
вилу: 

VAR3=VAR2. op. VAR1 

где op — код операции. Если переменные VAR1 и VAR2 — дан¬ 
ные различных типов, то данные, тип которых принадлежит бо- 
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лее низкому уровню иерархии типов, преобразуются в форму 
данных более высокого уровня. Иерархия типов данных в по¬ 
рядке возрастания их уровней имеет следующий вид: логиче¬ 
ские величины, числа с фиксированной точкой, числа с плаваю¬ 
щей точкой, символьные данные. VAR3 — логическая перемен¬ 
ная, принимающая одно из двух значений: TRUE (ИСТИННО) 
или FALSE (ЛОЖНО). Если переменные VAR1 и (или) 
VAR2 — указатели массивов, то выполняется сравнение эле¬ 
ментов двух массивов или элементов массива со скалярной ве¬ 
личиной; в этом случае VAR3 — указатель нового массива ло¬ 
гических величин. 

Имя команды. AND, OR 
Длина команды. 8 бит. 

Выполняемая операция. Выполнение логической операции над 
содержимым двух слов, находящихся в верхней части стека. 
Исходное содержимое стека. VAR1, VAR2, X 
Конечное содержимое стека. VAR3, X 

Операнды. Значения переменных VAR1 и VAR2 преобразуют¬ 
ся, если это требуется, в логические величины, после чего вы¬ 
полняется соответствующая операция и переменная VAR3 при¬ 
нимает то или иное логическое значение. Если переменные 
VAR1 и (или) VAR2 — указатели массивов, то операция вы¬ 
полняется над элементами массивов, а переменная VAR3 — 
указатель нового массива. 

Имя команды. PLUS, NEG 
Длина команды. 8 бит. 

Выполняемая операция. Сохранение неизменным (по команде 
PLUS) или изменение на противоположный (по команде NEG) 
знака операнда. 

Исходное содержимое стека. VAR1, X 
Конечное содержимое стека. VAR2, X 

Операнды. Переменная VAR1 —логическая величина, число с 
фиксированной или плавающей точкой. Если это логическая ве¬ 
личина, то она преобразуется в число с фиксированной точкой. 
В результате выполнения команды PLUS имеет место соотно¬ 
шение VAR2=VAR1, а реализация команды NEG приводит к 
равенству VAR2=—VAR1. Если переменная VAR1 служит 
указателем массива, то формируется новый массив, при этом 
переменная VAR2 является указателем нового массива. 

Имя команды. NOT 
Длина команды. 8 бит. 

Выполняемая операция. Формирование логического дополнения 
операнда. 


13* 



Исходное содержимое стека. VAR1, X 
Конечное содержимое стека. VAR2, X 

Операнды. Если необходимо, то переменная VAR1 преобра¬ 
зуется в логическую величину; в результате выполнения коман¬ 
ды логическое дополнение этой величины присваивается пере¬ 
менной VAR2. Если переменная VAR 1—указатель массива, 
то формируется новый массив, указателем которого является 
VAR2. 

Имя команды. BIT 
Длина команды. 8 бит. 

Выполняемая операция. Преобразование операнда в логиче¬ 
скую величину. 

Исходное содержимое стека. VAR1, X 
Конечное содержимое стека. VAR2, X 

Операнды. Переменная VAR1 —логическая величина либо 
число с фиксированной или плавающей точкой. Если значение 
переменной VAR1 равно нулю, то значение логической пере¬ 
менной VAR2 ложно, иначе — истинно. 

КОМАНДЫ УПРАВЛЕНИЯ 

Имя команды. CALL 
Длина команды. 8 бит. 

Выполняемая операция. Приостановка выполнения текущего 
сегмента программы и инициирование выполнения другого сег¬ 
мента. 

Исходное содержимое стека. VAR, X 
Конечное содержимое стека. X 

Операнды. Переменная VAR — дескриптор сегмента програм¬ 
мы. В стеке сегментов программ формируется адрес точки вхо¬ 
да в новый сегмент. 

Примечание. Эта команда — не обращение к процедуре, по¬ 
скольку не предусмотрена передача параметров и не происхо¬ 
дит изменения лексического уровня. Команда используется для 
реализации операторов IF и DO. Команда CALL по производи¬ 
мому действию подобна оператору PERFORM языка КОБОЛ. 

Имя команды. DOSTORE 
Длина команды. 8 бит. 

Выполняемая операция. Запись содержимого слова, находяще¬ 
гося на вершине стека, в область памяти, адресуемую вторым 
словом стека. 

Исходное содержимое стека. VAR1, VAR2, X 
Конечное содержимое стека. VAR2, X 

Операнды. Переменная VAR2 — дескриптор косвенного адреса 
или дескриптор элемента массива. 
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Примечание. Команда DOSTORE предназначена для иницииро¬ 
вания итеративного цикла DO, причем переменная VAR1 — на¬ 
чальное значение параметра цикла, а переменная VAR2 — его 
текущее значение. Команда DOSTORE выполняет ту же опера¬ 
цию, что и команда STORE, но имеет более ограниченный диа¬ 
пазон действия. При необходимости переменная VAR1 пре¬ 
образуется в форму, соответствующую типу переменной 
VAR2. 


Имя команды. DOTEST 
Длина команды. 8 бит. 

Выполняемая операция. Сравнение двух величин с целью опре¬ 
деления, равны ли они, а если нет, то которое из них больше 
(меньше). 

Исходное содержимое стека. VAR1, VAR2, VAR3, X 
Конечное содержимое стека. VAR4, VAR1, VAR2, VAR3, X 
Операнды. Переменная VAR3 — дескриптор косвенного адреса 
числовой величины. Переменные VAR1 и VAR2 — числовые 
величины. VAR4 — логическая переменная, значение которой 
истинно, если 1) значение переменной VAR1 больше нуля, а со¬ 
держимое слова, адресуемого переменной VAR3, меньше или 
равно значению переменной VAR2; 2) значение переменной 
VAR1 меньше нуля, а содержимое слова, адресуемого перемен¬ 
ной VAR3, больше или равно значению переменной VAR2. 
Примечание. Команда DOTEST предназначена для организа¬ 
ции итеративных циклов DO, причем переменная VAR1 —при¬ 
ращение, переменная VAR2 — предельное значение, а перемен¬ 
ная VAR3 — текущее значение параметра цикла. 

Имя команды. CRET 
Длина команды. 8 бит. 

Выполняемая операция. Возврат в предшествующий сегмент 
программы, если логическая величина, находящаяся на верши¬ 
не стека, имеет значение «ложно». 

Исходное содержимое стека. VAR, X 
Конечное содержимое стека. X 

Операнды. VAR — логическая переменная. Если ее значение 
равно 1 (истинно), то выполняется следующая команда дан¬ 
ного сегмента программы. Если же значение VAR равно О 
(ложно), то выполнение текущего сегмента программы прекра¬ 
щается и возобновляется выполнение предшествующего сег¬ 
мента. 

Примечание. Команда CRET предназначена для выполнения 
циклов DO WHILE и итеративных циклов DO. В итеративном 
цикле эта команда следует за командой DOTEST. 
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Имя команды. DOINCR 
Длина команды. 8 бит. 

Выполняемая операция. Увеличение содержимого третьего от 
вершины стека слова на величину, находящуюся на вершине 
стека. 

Исходное содержимое стека. VAR1, VAR2, VAR3, X 
Конечное содержимое стека. VAR1, VAR2, VAR3, X 
Операнды. Переменная VAR3 — дескриптор косвенного адреса, 
по которому находятся числовые данные. Переменная VAR1 — 
числовая величина. Переменная VAR1 добавляется к числовым 
данным, адресуемым VAR3. 

Примечание. См. примечание к описанию команды DOTEST. 

Имя команды. CYCLE 
Длина команды. 8 бит. 

Выполняемая операция. Возврат управления первой команде 
данного сегмента программы. 

Исходное содержимое стека. X 
Конечное содержимое стека. X 

Примечание. Команда CYCLE предназначена для организации 
циклов DO. 

Имя команды. GO ТО 
Длина команды. 8 бит. 

Выполняемая операция. Передача управления команде, указы* 
ваемой дескриптором метки. 

Исходное содержимое стека. VAR, X 
Конечное содержимое стека. X 

Операнды. Переменная VAR — дескриптор косвенного адреса 
дескриптора метки-константы или метки-переменной. Если 
команда, которой передается управление, находится в данный 
момент в неактивизированном сегменте программы, то выпол¬ 
нение всех активизированных сегментов завершается, и, если 
это необходимо, производится обновление содержимого дис¬ 
плей-регистров. 

Имя команды. HALT 
Длина команды. 8 бит. 

Выполняемая операция. Завершение выполнения программы. 
Исходное содержимое стека. X 
Конечное содержимое стека. О 

Имя команды. LINE 
Длина команды. 16 бит. 

Выполняемая операция. Загрузка числа N в регистр номера 
оператора исходной программы. 
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Содержимое информационного поля команды: N (слово длиной 
8 бит). 

Исходное содержимое стека. X 
Конечное содержимое стека. X 


КОМАНДЫ РАБОТЫ С ПРОЦЕДУРАМИ 

Имя команды. ENTER 
Длина команды. 16 бит. 

Выполняемая операция. Прекращение выполнения текущего 
сегмента программы и начало выполнения другого сегмента, 
возможно находящегося на другом лексическом уровне. 
Содержимое информационного поля команды. N — число пере* 
даваемых параметров (слово длиной 8 бит). 

Исходное содержимое стека. VARP, VAR1, .... VARN, X 
Конечное содержимое стека. Указатель памяти для вызываемой 
процедуры, VAR1 . VARN, X 

Операнды. Переменная VARP — дескриптор косвенного адреса 
дескриптора сегмента программы. VAR1 — VARN — дескрипто¬ 
ры косвенных адресов фактических параметров. Команда 
ENTER проверяет совпадения числа и типов фактических па¬ 
раметров с числом и типами формальных параметров процеду¬ 
ры. Она распределяет память о стеке данных для переменных 
нового сегмента программы, присваивает формальным пара¬ 
метрам процедуры в качестве начальных значений значения, 
определяемые дескрипторами косвенных адресов фактических 
параметров, помещает соответствующие элементы в стек указа¬ 
телей активизируемых сегментов программы и стек указателей 
сегментов программы, а также обновляет содержимое дисплей- 
регистров. Если фактический параметр и соответствующий фор¬ 
мальный параметр процедуры отличаются типами данных, ко¬ 
торые они представляют, и при этом возможно корректное пре¬ 
образование формата данных, то дескриптор косвенного адреса 
фактического параметра замещается дескриптором преобразо¬ 
ванного надлежащим образом фактического параметра. 
Примечание. Команда ENTER используется для вызова проце¬ 
дур и процедур-функций и организации входа в блоки BEGIN 

Имя команды. SCOPEID 
Длина команды. 16 бит. 

Выполняемая операция. При выполнении этой команды не про¬ 
изводится никаких операций. 

Содержимое информационного поля команды. М — адрес эле¬ 
мента таблицы областей действия переменных, соответствующе¬ 
го данному сегменту программы (слово длиной 8 бит). 
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Исходное содержимое стека. X 
Конечное содержимое стека. X 

Примечание. Команда SCOPEID должна быть -первой командой 
любого сегмента программы, вызываемого по команде ENTER. 
Величина М используется командой ENTER для определения 
местоположения соответствующего элемента в памяти таблицы 
областей действий переменных. 

Имя команды. END 

Выполняемая операция. Завершение выполнения сегмента про¬ 
граммы, вызванного по команде ENTER, и возобновление вы¬ 
полнения вызывающего сегмента. 

Содержимое информационного поля команды. М — адрес эле¬ 
мента таблицы областей действия переменных, соответствую¬ 
щего данному сегменту программы (слово длиной 8 бит). 
Исходное содержимое стека. VAR, X 
Конечное содержимое стека. VAR, XI 

Операнды. Переменная VAR является величиной, поступающей 
обратно в вызывающий сегмент программы. XI —разность зна¬ 
чений содержимого стека в начале выполнения -соответствую¬ 
щей команды ENTER и переменной VARP (дескриптора кос¬ 
венного адреса дескриптора сегмента программы). Команда 
END восстанавливает предшествующее состояние стека указа¬ 
телей активизируемых сегментов программы и стека указате¬ 
лей сегментов программы, а также обновляет содержимое дис¬ 
плей-регистров. 

Имя команды. PARAM. 

Длина команды. 16 бит. 

Выполняемая операция. Приостановка выполнения текущего 
сегмента программы и инициирование выполнения процедуры, 
если операнд команды указывает процедуру. Если операнд не 
указывает процедуру, то никаких операций не производится и 
содержимое стека сохраняется неизменным. 

Содержимое информационного поля команды. Р — число (сло¬ 
во длиной 8 бит). 

Исходное содержимое стека. VAR1, VAR2, X 

Конечное содержимое стека. Указатель памяти для вызываемой 

процедуры, VAR2, X 

Операнды. Переменная VAR1 —дескриптор косвенного адреса 
фактического параметра. Число Р указывает, что VAR1 пред¬ 
ставляет Р-й параметр для процедуры, указываемой VAR2. 
(Переменная VAR2 — дескриптор косвенного^ адреса дескрип¬ 
тора сегмента программы.) Если фактический параметр — имя 
процедуры-функции без параметров, замещаемое в результате 
ее работы некоторой величиной (т. е. если VAR1 указывает 
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дескриптор сегмента программы), то в сегмент, определяемый 
VAR1, управление передается так, как если бы команда ENTER 
была выполнена. 

Примечание. Команда PARAM используется для определения 
того, является ли формальный параметр процедуры, соответст¬ 
вующий передаваемому фактическому параметру, именем про¬ 
цедуры, или нет. В последнем случае значение фактического 
параметра должно быть определено. Компилятор генерирует 
команды PARAM перед каждой командой ENTER. 

Имя команды. LFUNC 
Длина команды. 16 бит. 

Выполняемая операция. Приостановка выполнения текущего 
сегмента программы и начало выполнения другого сегмента, 
представляющего псевдопеременную. 

Содержимое информационного поля команды. N — число факти¬ 
ческих параметров (слово длиной 8 бит). 

Исходное содержимое стека. VARR, VARF, VAR1 . VARN, X 

Конечное содержимое стека. Не определено. 

Операнды. Переменная VARR — дескриптор косвенного адреса 
величины, преобразуемой в строку символов. Переменная 
VARF — дескриптор косвенного адреса числа с фиксированной 
точкой, для которого вызывается соответствующая встроенная 
функция. Переменные VAR1 — VARN — дескрипторы адресов 
фактических параметров. 

Примечание. Команда LFUNC используется для представления 
псевдопеременных OUTPUT и SUBSTR в левой части операто¬ 
ров присваивания. Переменная VARR представляет значение 
правой части оператора присваивания. Действие команды 
LFUNC подобно обращению к супервизору. 

КОМАНДЫ УПРАВЛЕНИЯ 
ПАМЯТЬЮ МАССИВОВ 

Имя команды. ALLOC 
Длина команды. 16 бит. 

Выполняемая операция. Распределение памяти для массива 
данных. 

Содержимое информационного поля команды. D — число, обо¬ 
значающее размерность массива (слово длиной 8 бит). 
Исходное содержимое стека. VARA, VARL1, VARU1, ..., VARLD, 
VARUD, X 

Конечное содержимое стека. X 

Операнды. Переменная VARA — дескриптор косвенного адреса 
указателя массива. Переменные VARL1 — VARUD — числа с 
фиксированной точкой, представляющие собой минимальное и 
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максимальное граничные значения индексов для каждого из¬ 
мерения массива. Команда ALLOC распределяет память для 
элементов массива (в верхней части стека данных), формиру¬ 
ет дескриптор в памяти дескрипторов массивов и записывает 
адрес дескриптора в указатель массива. Если существовала 
предыдущая версия массива (т. е. если указатель массива не 
является неопределенной величиной), то дескриптор нового 
массива указывает местоположение дескриптора предшествую¬ 
щей версии массива. 

Имя команды. FREE 
Длина команды. 8 бит. 

Выполняемая операция. Освобождение памяти, занимаемой 
массивом или одной из версий массива. 

Исходное содержимое стека. VARA, X 
Конечное содержимое стека. VARA, X 

Операнды. VARA — дескриптор косвенного адреса указателя 
массива. Освобождается память, занимаемая элементами мас¬ 
сива, а также относящимся к массиву дескриптором (в памяти 
дескрипторов массивов). Если существует ранее созданная вер¬ 
сия массива (дескриптор массива содержит ссылку на дескрип¬ 
тор другого массива), то указатель массива модифицируется 
так, чтобы указывать на дескриптор следующего массива; если 
такой версии массива нет, то указатель массива помечается 
как неопределенный. 


ЧАСТЬ III 

АРХИТЕКТУРА МАШИН 
ЯЗЫКОВ ПРОГРАММИРОВАНИЯ 
ВЫСОКОГО УРОВНЯ 


ГЛАВА 8 

АРХИТЕКТУРА СИСТЕМЫ SYMBOL 

В качестве второго объекта анализа достижений в совершенст* 
вовании архитектуры ЭВМ выбрана функционирующая вычис¬ 
лительная система SYMBOL [1—28], разработанная фирмой 
Fairchild Camera and Instrument. Единственный сконструиро¬ 
ванный образец этой системы изучался в течение нескольких 
лет в Университете шт. Айова, после чего от использования 
этой системы отказались. 

Система SYMBOL была разработана в результате выполне¬ 
ния большого исследовательского проекта по анализу и пере¬ 
смотру традиционного подхода к разделению функций, реали¬ 
зуемых вычислительной системой, между аппаратными средст¬ 
вами и программным обеспечением. Цели проводимого иссле¬ 
дования заключались в следующем: 

1. Спроектировать вычислительную систему с существенно 
повышенной по сравнению с обычными системами производи¬ 
тельностью и меньшей стоимостью вычислений за счет непо¬ 
средственной аппаратной реализации языка программирова¬ 
ния высокого уровня, виртуальной памяти и режима разделения 
времени операционной системы. 

2. Создать систему, ориентированную не столько на тради¬ 
ционную обработку числовых данных, сколько на работу с не¬ 
числовой информацией и данными сложной структуры. 

3. Разработать новые принципы проектирования и методы 
конструирования аппаратных средств (одним из результатов 
исследований в указанном направлении явилась разработка кор¬ 
пусов интегральных схем с двурядным расположением выводов; 
эти корпусы пользуются и в настоящее время высоким спросом). 

4. Продемонстрировать реализуемость сформулированных 
выше целей путем создания полноценной и работоспособной 
системы. 

Придерживаясь классификации, приведенной в гл. 3, архи¬ 
тектуру системы SYMBOL можно отнести к архитектуре типа Б 
машин языков высокого уровня. Набор команд рассматривав- 
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мой вычислительной системы — это префиксная запись опера¬ 
торов языка программирования SPL (SYMBOL Programming 
Language — язык программирования SYMBOL), причем компи¬ 
лирование выполняется в значительной мере аппаратными, а не 
программными средствами. 

Уже первая из сформулированных выше целей создания си¬ 
стемы SYMBOL доівольно необычна. Словосочетание «непосред¬ 
ственная аппаратная реализация» означает, что система факти¬ 
чески не содержит программного обеспечения. Точнее говоря, 
определенные средства программного обеспечения имеются, но 
выполняют только несколько второстепенных функций, так что 
система может работать без них. Кроме того, в системе отсут¬ 
ствуют микропрограммы, все ее функции реализуются набором 
последовательностных логических схем. Например, трансля¬ 
тор— это аппаратно выполненная последовательностная схема; 
алгоритмы адресации памяти и замещения страниц памяти реа¬ 
лизуются с помощью последовательностных логических схем; 
команды, вводимые пользователем с терминала, обрабатывают¬ 
ся последовательностными логическими схемами и т. д. Хотя 
описанное может показаться самой необычной характеристикой 
системы SYMBOL, эту характеристику не относят к главным, 
поскольку она оказывается одним из недостатков системы, так 
как указанные здесь функции системы могли быть обеспечены 
средствами микропрограммирования. Следует заметить, что в 
начале работы над проектом, т. е. в середине 60-х годов, микро¬ 
программное управление еще не было широко распространен¬ 
ным средством реализации функций вычислительной системы. 

Для пользователя система SYMBOL представляется терми¬ 
нально-ориентированной системой с виртуальной памятью, ра¬ 
ботающей в режиме разделения времени и поддерживающей 
язык SPL. Внутренняя организация и машинный язык системы 
не доступны пользователю. Он выполняет отладку программы, 
пользуясь языком программирования, и никогда не имеет дела 
с традиционными машинными адресами или дампом оператив¬ 
ной памяти. 

КОНФИГУРАЦИЯ СИСТЕМЫ 

По внутренней организации система SYMBOL является 
мультипроцессорной системой, которая, однако, отличается от 
традиционных мультипроцессорных систем двумя уникальными 
свойствами. Во-первых, пользователь находится в абсолютном 
неведении относительно того, что эта система мультипроцессор¬ 
ная. Во-вторых, каждый процессор предназначен для выполне¬ 
ния определенной функции: один — для компилирования про¬ 
грамм, написанных на языке SPL; другой — для диспетчериза- 
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ции и управления обменом страницами (их «перелистывани¬ 
ем»), третий — для обработки команд, поступающих с термина¬ 
ла; четвертый — для управления памятью; пятый — для выпол¬ 
нения программ пользователя и т. д. 

Процессоры, входящие в состав системы, и их взаимосвязи 
показаны на рис. 8.1. Число, находящееся в правом нижнем 



Рис. 8.1. Функциональная схема мультипроцессорной системы SYMBOL. 


углу каждого блока, — мера относительной сложности соответ¬ 
ствующего процессора; оно обозначает количество монтажных 
плат в процессоре. Каждая плата содержит ~200 интеграль¬ 
ных схем или ~ 800 вентилей. 

Функции, реализуемые каждым процессором, рассматрива¬ 
ются в гл. 9 и 10, однако их краткое описание целесообразно 
привести здесь. Для каждого процессора имеется своя очередь 
запросов, которые должны быть обслужены, и все процессоры 
могут работать одновременно. Программа пользователя пере¬ 
ходит от одного процессора к другому по мере того, как возни- 
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кает необходимость в реализации различных функций, связан¬ 
ных с выполнением программы. Для конкретной программы 
пользователя в данный момент всегда работает только один 
процессор. Таким образом, с точки зрения отдельного пользова¬ 
теля система представляется однопроцессорной. 

Контроллер каналов ввода-вывода является промежуточным 
звеном между 32 каналами ввода-вывода (каждый из которых 
представляет собой удаленный терминал или локальное пери¬ 
ферийное устройство ввода-вывода) и связанных с этими кана¬ 
лами буферами в основной памяти. Процессор интерфейса вво¬ 
да-вывода также выполняет функции, относящиеся к организа¬ 
ции ввода-вывода данных. Когда буфер ввода заполнен, этот 
процессор передает содержимое буфера в соответствующую 
область виртуальной памяти, выделенную пользователю. Про¬ 
цессор интерфейса ввода-вывода работает так же, как и систе¬ 
ма управления вводом-выводом традиционной операционной 
системы: при выполнении команды ввода или вывода, содержа¬ 
щейся в программе пользователя, управление выполнением этой 
операции ввода-вывода осуществляется данным процессором. 
Процессор интерфейса ввода-вывода реализует также функции 
подсистемы обработки директив пользователя традиционной 
системы разделения времени. Например, если пользователь со 
своего терминала редактирует текст исходной программы, та 
команды редактирования обрабатываются данным процессо¬ 
ром, благодаря чему другие процессоры оказывают незагружен¬ 
ными и могут выполнять запросы других пользователей. 

Транслятор представляет собой отдельный процессор, един¬ 
ственной функцией которого является компилирование програм¬ 
мы. Эта функция заключается в выборке программ на языке 
SPL из входной очереди транслятора и их компилировании в 
объектные программы. 

Единственной функцией центрального процессора является 
выполнение объектных программ. Как показано на рис. 8.1» 
центральный процессор в действительности состоит из четырех 
отдельных подпроцессоров. Эти процессоры работают последо¬ 
вательно, так что в любой момент времени центральный про¬ 
цессор выполняет только одну программу. 

Четыре процессора являются обслуживающими: они не вы¬ 
полняют самостоятельно определенных функций системы, а об¬ 
рабатывают запросы других процессоров. Так, контроллер па¬ 
мяти обслуживает запросы других процессоров на чтение ин¬ 
формации из памяти или запись ее в память. Это устройство 
позволяет другим процессорам «представлять» память с высо¬ 
кой степенью абстракции: для других процессоров память —это 
бесконечное число списков бесконечной длины. Такое представ¬ 
ление памяти и соответствующих процессов управления ею яв- 
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ляется основной особенностью системы SYMBOL и обсуждается 
более детально в гл. 10. 

Вторым обслуживающим процессором является регенератор 
памяти. Вследствие того что контроллер отображает логиче¬ 
скую структуру памяти (списковые структуры) в виртуальную 
память, а виртуальной памяти ставит в соответствие адекват¬ 
ные разделы основной памяти, обслуживание запросов процес¬ 
сора на освобождение памяти требует значительного времени. 
Поэтому вместо того, чтобы обрабатывать такие запросы после¬ 
довательно, связывая между собой запрашивающий процессор 
и контроллер памяти на чрезмерно большой интервал времени, 
контроллер памяти просто помечает соответствующую область 
как недоступную каким-либо запросам и помещает ее в очередь 
на освобождение к регенератору памяти. 

Третий процессор—это супервизор системы (или просто су¬ 
первизор), выполняющий функции, аналогичные функциям 
диспетчеризации и управления страничным обменом традици¬ 
онной операционной системы. Супервизор управляет очередями 
к другим процессорам и планирует операции манипулирования 
страницами, когда один из процессоров, производя обращение к 
контроллеру памяти, сталкивается с проблемой отсутствия тре¬ 
буемой страницы в основной памяти. 

Последним обслуживающим процессором является контрол¬ 
лер памяти на магнитных дисках. Это устройство функциони¬ 
рует как управляемый очередью канал ввода-вывода; оно обра¬ 
батывает запросы, находящиеся в его очереди, и осуществляет 
передачу информации между основной памятью и внешними 
запоминающими устройствами. 

В системе имеется также процессор обработки сбоев. При 
нормальном функционировании системы этот процессор в ра¬ 
боте не участвует. Он используется для отладки, а также про¬ 
слеживания особых ситуаций, возникающих на основной шине, 
соединяющей все процессоры. Шина предназначена для переда¬ 
чи следующей информации: 

1) данных между любым процессором и контроллером па¬ 
мяти; 

2) управляющей информации между любым процессором и 
супервизором; 

3) данных между четырьмя компонентами центрального про¬ 
цессора. 

При посылке запросов к контроллеру памяти процессоры ис¬ 
пользуют основную шину поочередно согласно установленной 
для них системе приоритетов. 

Поскольку память является наиболее важным ресурсом си¬ 
стемы, установленный приоритет дает представление об отно¬ 
сительной значимости самих процессоров. Иерархия процессов 
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ров в порядке убывания их приоритетов доступа к памяти имеет 
следующий вид: супервизор, процессор интерфейса ввода-выво¬ 
да, центральный процессор, транслятор, регенератор памяти. 
Контроллер каналов ввода-вывода и контроллер памяти на 
дисках не включены в этот список, поскольку они не использу¬ 
ют контроллер памяти; данные устройства подключены непо¬ 
средственно к шине памяти (рис. 8.1). Третья шина использует¬ 
ся в центральном процессоре для передачи управляющей 
информации между четырьмя его компонентами. 

ПРОХОЖДЕНИЕ ПОТОКА ЗАДАНИЙ 
ЧЕРЕЗ СИСТЕМУ 

Динамику работы системы легче всего понять путем изучения 
прохождения потока заданий пользователей от процессора к 
процессору. Для этого сделаем ряд простейших допущений. 
Предположим, что вызов новых страниц виртуальной памяти не 
производится, т. е. все необходимые данные находятся в основ¬ 
ной памяти. Известно, что каждый процессор обрабатывает по¬ 
мещенные в его очередь запросы в течение некоторого предель¬ 
но допустимого интервала времени. Мы будем полагать, что 
время полной обработки запроса не выходит за пределы этого 
интервала. «Перелистывание» страниц виртуальной памяти и 
временная коммутация обслуживания запросов (путем разбие¬ 
ния времени обработки одного запроса на отдельные интерва¬ 
лы) описываются в гл. 10. 

Терминал пользователя системы SYMBOL имеет в добавле¬ 
ние к обычной буквенно-цифровой клавиатуре набор функцио¬ 
нальных клавиш для ввода команд управления системой. При¬ 
мерами таких клавиш являются следующие: LOAD, RUN, 
PAUSE, CONTINUE, SEARCH, REMOVE, FORWARD, 
BACKWARD, DISPLAY, причем последние пять клавиш пред¬ 
назначены для выполнения функций редактирования исходного 
текста на экране дисплея. Первоначально будем полагать, что 
пользователь работает в режиме загрузки, ввода и редактиро¬ 
вания текста. При этом используются только четыре процессо¬ 
ра: супервизор, контроллер каналов ввода-вывода, процессор- 
интерфейса ввода-вывода и контроллер памяти. Весьма веро¬ 
ятно, что эти четыре процессора в то же время выполняют за¬ 
просы других пользователей, а транслятор и центральный про¬ 
цессор работают независимо, обрабатывая задания других, 
пользователей. 

Если пользователь вводит со своего терминала строку тек¬ 
ста (например, оператор написанной им программы), то конт¬ 
роллер каналов ввода-вывода принимает каждый символ и по¬ 
мещает его в буфер строк, относящийся к этому терминалу и- 
расположенный в зарезервированной для него области основной 
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памяти. После заполнения буфера контроллер каналов ввода- 
вывода посылает супервизору сигнал «Буфер заполнен» и пере¬ 
ключает данный терминал на запасной буфер. Супервизор по¬ 
мещает запрос в очередь к процессору интерфейса ввода-выво¬ 
да, указывая ему на необходимость передачи содержимого за¬ 
полненного буфера во временную рабочую область пользова¬ 
теля. «Встретив» этот запрос в своей входной очереди, процес¬ 
сор интерфейса ввода-вывода пересылает содержимое буфера в 
рабочую область, обращаясь для этой цели с надлежащими за¬ 
просами к контроллеру памяти. 

Если пользователь нажимает одну из командных клавиш 
(например, клавишу BACKWARD для перемещения указателя 
текущей строки в рабочей области назад на одну строку)» 
контроллер каналов ввода-вывода принимает соответствующий 
управляющий символ. Выяснив, что принят управляющий сим¬ 
вол, контроллер не помещает его в буфер, а посылает суперви¬ 
зору. Если управляющий символ запрашивает выполнение опе¬ 
рации редактирования текста (например, BACKWARD), то» 
супервизор помещает запрос в очередь процессора интерфейса 
ввода-вывода. Когда наступит очередь обработки данного за¬ 
проса, указанный процессор выполнит требуемую операцию ре¬ 
дактирования, обращаясь для этой цели к контроллеру памяти.. 

Другие действия производятся, когда пользователь нажи¬ 
мает клавишу RUN, инициирующую транслирование и выпол¬ 
нение программы, находящейся во временной рабочей облает» 
пользователя. Как и ранее, контроллер каналов ввода-вывода 
распознает управляющий символ и посылает его супервизору. 
Последний создает входной элемент в очереди запросов транс¬ 
лятора. В дальнейшем транслятор выберет данный элемент иа 
своей очереди и начнет компилирование программы. 

Транслятор выполняет функции как компилирования, так » 
редактирования программы. Если в программе встречается так 
называемая неразрешенная ссылка на процедуру, то транслятор» 
выбирает эту процедуру из соответствующей библиотеки про¬ 
грамм 1 ). (Библиотеки программ входят в состав файлов систе¬ 
мы, которые отображаются в виртуальной памяти, образуя та¬ 
ким образом одноуровневую память.) Завершив компилирова¬ 
ние программы, транслятор, производя обращение с соответст¬ 
вующими запросами к контроллеру памяти, создает в памяти- 
два списка: объектный код программы и одну или более таблиц, 
символических имен. 

Транслятор работает настолько быстро, что было принято 
решение хранить все программы (речь идет о программах и 


') «Разрешение» подобной ссылки как раз и заключается в описываемы* 
действиях транслятора. — Прим, перев. 


14—283 
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библиотеках) в исходной форме. Если не учитывать операций 
ввода-вывода и «перелистывания» страниц виртуальной памя¬ 
ти, то средняя скорость компилирования равна 75000 опера¬ 
тор/мин. В оптимизированной версии системы SYMBOL, кото¬ 
рая была спроектирована, но так никогда и не была сконструи¬ 
рована, транслятор должен был обеспечить компилирование в 
среднем 300 000 оператор/мин [2]. 

При завершении компилирования программы транслятор 
извещает об этом супервизор системы. Супервизор помещает 
соответствующий запрос во входную очередь центрального про¬ 
цессора. В соответствии с очередностью этого запроса цент¬ 
ральный процессор начинает выполнение программы. Централь¬ 
ный процессор использует контроллер памяти для доступа к 
объектному коду программы и таблицам символических имен, 
выделения памяти для переменных программы и изменения 
значений этих переменных. Если центральный процессор встре¬ 
чает в объектном коде команду ввода-вывода, то он обращает¬ 
ся к супервизору, который помещает запрос на ввод-вывод в 
очередь процессора интерфейса ввода-вывода. 

Может показаться, что в системе SYMBOL все межпроцес¬ 
сорные связи должны приводить к значительному расходу ма¬ 
шинного времени. Хорошим способом оценки данного фактора 
и сравнения системы SYMBOL с традиционной системой разде¬ 
ления времени является анализ времени, требуемого для ком¬ 
пилирования и выполнения программы, состоящей из одного 
оператора и не совершающей никакой обработки. Для случая, 
когда с системой работает единственный пользователь, интер¬ 
вал времени от приема команды RUN до завершения выполне¬ 
ния программы составляет 315 мкс. Применение такого же кри¬ 
терия для оценки традиционной системы показывает, что здесь 
временной интервал более 315 мкс требуется только для анали¬ 
за команды на выполнение компилирования, не говоря уже о 
времени, затрачиваемом на запуск транслятора. Подобная 
оценка производительности системы SYMBOL (315 мкс) пред¬ 
ставляется еще более удивительной, если принять во внимание, 
что фактором, ограничивающим быстродействие системы, яв¬ 
ляется использование относительно медленнодействующей фер¬ 
ритовой памяти с временем цикла обращения к 64-разрядному 
слову, равным 4 мкс. 

ЯЗЫК ПРОГРАММИРОВАНИЯ 
СИСТЕМЫ SYMBOL 

Язык программирования системы SYMBOL — SPL является 
обычным языком программирования высокого уровня общего 
назначения. Поскольку машинный язык центрального процессо- 
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ра представляет собой, по существу, реализацию «один — к — 
одному> обратной польской записи операторов языка SPL, то 
имеет смысл вначале познакомиться с языком SPL, а затем 
перейти к рассмотрению архитектуры центрального процессора. 

Язык SPL можно рассматривать как совокупность положе¬ 
ний, лежащих в основе таких языков, как APL, ПЛ/1 и ЛИСП. 
Подобно языку APL, данный язык не содержит типов перемен¬ 
ных [отсутствуют операторы описания переменных, а атрибуты 
(определители) переменных могут быть изменены во время вы¬ 
полнения программы]; в языке SPL имеется только несколько 
базовых типов данных и структур. Язык SPL подобен языку 
ПЛ/1 по синтаксису, наличию блочных структур и использова¬ 
нию оператора ON, а языку ЛИСП тем, что первичной структу¬ 
рой данных является список. 

Язык SPL оперирует данными двух категорий: скалярами и 
списками (называемыми структурами). Скаляр —это строка 
символов цроизвольной длины. Для манипулирования скаляра¬ 
ми в языке предусмотрено 20 операций. В качестве иллюстра¬ 
ции приведем следующий фрагмент программы: 

Ач-22.3; 

B-«-|abcD$|; 

С-«-А join В; 

OUTPUT С; 

В результате выполнения этих операций на терминал выво¬ 
дится строка 22.3abcD$. Знак «|» (вертикальная черта) исполь¬ 
зуется как символ — разделитель литеральных скалярных ве¬ 
личин, однако его можно использовать и для скаляров, имею¬ 
щих синтаксическое строение числовых величин. В языке SPL 
предусмотрен набор операций и над такими числовыми скаля¬ 
рами. Речь идет о скалярах, подобных следующим: 

0.5 3.14159ЕМ 

486 32.2ЕХ 

Хотя в общем случае длина скаляра не ограничена (на 
практике пределом является размер предоставляемой области 
памяти), максимальная длина используемых числовых скаля¬ 
ров не должна превышать 99 цифр. Числовые величины всегда 
записываются в памяти машины о виде мантиссы и порядка. 
Мантисса может содержать 1—99 цифр, а порядок—1 или 
2 цифры. Все арифметические операции выполняются в деся¬ 
тичной системе счисления. 

Запись в память числовых величин с переменным (не фик¬ 
сированным) количеством цифр может привести к увеличению 
времени обработки и излишнему расходу памяти, поскольку, 
например, в результате выполнения оператора А-«—1/3; в па- 

14 * 
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мять записывается число .3333..., состоящее из 99 цифр. Для 
устранения данного недостатка в структуру языка SPL допол¬ 
нительно введены псевдопеременная LIMIT и атрибуты данных 
ЕХ и ЕМ 1 *. Псевдопеременная LIMIT может использоваться 
программистом для задания размерности внутреннего пред¬ 
ставления результата выполнения последующей операции над 
числовыми данными. Например, фрагмент программы 

LIMITS-5; 

A-t-1 /З; 

присваивает переменной А значение .ЗЗЗЗЗЕМ. Атрибут данных 
ЕМ, записываемый вместе со значением переменной А, указы¬ 
вает на то, что А представлена не точным значением. Правила 
выполнения операций над числовыми скалярами определяют 
длину результата следующим образом: 

1) длина результата меньше текущего значения псевдопере¬ 
менной LIMIT; 

2) если хотя бы один операнд представлен неточно (т. е. 
имеет определитель ЕМ), то длина результата меньше длины 
самого короткого операнда. Если, согласно данному правилу, 
отбрасываются ненулевые цифры результата или если один из 
операндов представлен приближенно, то результат помечается 
как приближенно определенная величина. Проиллюстрируем 
это следующим фрагментом программы: 

LIMIT^-5; 

Ач-1/3; результат=. ЗЗЗЗЗЕМ 

Вч-1,0; результат=1.0000ЕХ 

LIMIT-MO; 

О-В/А; результат=3.0000ЕМ 

D-«-B; результат= 1 .000000000ЕХ 

Еч -D'A; результат=.ЗЗЗЗЗЕМ 

Чтобы проверить, представлен ли результат операции с точ¬ 
ностью, определяемой псевдопеременной LIMIT, достаточно 
предусмотреть в программе анализ значения логической пере¬ 
менной LIMIT. 

В языке SPL имеется набор логических операций, опреде¬ 
ленных для скаляров, содержащих только нули или единицы. 

структуры 

Структура — это упорядоченный список, каждый элемент кото¬ 
рого может быть скаляром или структурой. Структура может 
использоваться в качестве массива, но она является более эф- 

» Аббревиатура ЕХ происходит от английского слова exact — «точный», 
ЕМ — от английского empirical — «приближенный». — Прим, перед. 
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фективной формой представления данных, чем массив, посколь¬ 
ку ее размер и конфигурация могут изменяться динамически, 
в ее элементы не обязательно должны иметь одинаковые атри¬ 
буты. 

Знаки «(» и «>» используются в качестве символов-разде¬ 
лителей для определения начала и конца структуры как неко- 
тррого литерала, а знак «|»—в качестве символа-разделителя 
элементов структуры. Следующий фрагмент дает представле- 
«не о некоторых свойствах структур: 


Ач-<100|200|300>; 
OUTPUT А[1]; 
A[4]-«-|WXYZ|; 
OUTPUT А; 
А[1]ч-(1011102); 
OUTPUT А Г1,2]; 
OUTPUT А; 

Вч-А; 

OUTPUT В; 
В[1]ч-Ю0; 
OUTPUT В; 


результат =100 

результат=< 100120013001 WXYZ) 
результат=102 

результат = «1011102) 120013001 WXYZ) 
результат =« 1011102) 20013001 WXYZ) 
результат=< 100120013001 WXYZ) 


Любая ссылка на несуществующий элемент структуры при¬ 
водит к появлению такого элемента. Например, в результате 
выполнения оператора А[6]ч-В; структура В помещается в ше¬ 
стой элемент структуры А, а элементу А[5] будет присвоено ну¬ 
левое значение. 


СТРУКТУРА ПРОГРАММЫ 
И ОПЕРАТОРЫ ПЕРЕДАЧИ УПРАВЛЕНИЯ 

Язык SPL содержит операторы IFTHENELSE и GO ТО. Пред¬ 
полагалось включение в язык и оператора организации итера¬ 
тивного цикла LOOP, однако он не был реализован. 

В языке SPL имеются процедуры и процедуры-функции. Пе¬ 
редача фактических параметров процедуры или процедуры- 
функции осуществляется указанием имени передаваемого пара¬ 
метра, как это показано в следующем фрагменте программы: 
Ач-1; 

Вч-2; 

CALL W(A,A+B); 

PROCEDURE W(X, Y); 

OUTPUT Y; результат = 3 

Хч-Х+1; 

OUTPUT Y; результат = 4 

END 
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Подобно языкам АЛГОЛ и ПЛ/1, язык SPL ориентирован на 
блочную структуру программ с использованием правил, опре¬ 
деляющих области действия переменных во вложенных про¬ 
цедурах. Однако в отличие от упомянутых языков в языке SPL 
по умолчанию идентификатор воспринимается как локальный 
по отношению к процедуре, в которой он используется. Иден¬ 
тификатор может быть определен как синоним по отношению к 
идентичному идентификатору в вызывающей процедуре с по¬ 
мощью оператора GLOBAL. Оператор GLOBAL X; объявляет 
идентификатор X в данной процедуре синонимом идентифика¬ 
тора X вызывающей процедуры. 

В языке SPL предусмотрено также использование блоков 
ON, подобных цроцедурам, за исключением того, что способ 
обращения к блокам иной. Если в операторе ON указаны одно 
или несколько имен переменных, то передача управления в со¬ 
ответствующий блок ON производится сразу же по присвоении 
значения одной из переменных. Если в операторе ON заданы 
одна или несколько меток операторов, то блок ON вызывается 
перед передачей управления (с помощью оператора GO ТО) на 
одну из этих меток. Если в операторе ON перечислены одно или 
несколько имен процедур, то блок ON будет выполнен непо¬ 
средственно перед вызовом какой-либо из этих процедур. Опе¬ 
ратор ON может также использоваться для описания действий 
при возникновении ситуации INTERRUPT. В этом случае вызов 
блока ON будет производиться при поступлении црерывания с 
терминала. 

В табл. 8.1 приведен список операторов и операций, исполь¬ 
зуемых в языке SPL. 

В качестве иллюстрации структуры программы на языке 
SPL ниже приводится программа, написанная на учебном язы¬ 
ке ПЛ (эта программа заимствована из гл. 6), и эквивалентная 
программа на языке SPL. 


XYZ: PROCEDURE; 
DECLARE А(*) FLOAT; 
DECLARE (В,С) FIXED; 

В = 4; 

ALLOCATE А(1:В); 

А = 1; 

С = В + В * В; 

CALL ZZZ (В); 

А(В) = С; 

ZZZ: PROCEDURE (М); 
DECLARE М FIXED; 

С = М + М; 

END; 

END; 


В <— 4; 

I •*— 1; 

Li .IF I LTE В THEN 
A[i] <— i; 

I «- 1 + I; 

GO TO L; 

END 

С <- В + В * В; 

CALL ZZZ (В); 

A[B] ■«— C; 

PROCEDURE ZZZ (M); 
GLOBAL C; 

C«-M+ M; 

END 
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Таблица 8.1. Список операторов и операций языка SPL 


Операторы 


Операции 

INPUT 

SWITCH 

+ 

BEFORE 

OUTPUT 

ON 


SAME 

GO TO 

DISABLE 


AFTER 

IF 

Оператор присваи- 

ENABLE 

/ 

JOIN 

вания 

PROCEDURE 

ABS 

AND 


BLOCK 

GREATER 

OR 

CALL 

RETURN 

GTE 

NOT 

PAUSE 

GLOBAL 

EQUALS 

FORMAT 

CONTINUE 

SYSTEM» 

NEQ 

MASK 

LINK 

TRAP» 

Оператор установ¬ 

NOTE 

Обращение к па¬ 

LTE 

IN 

ки начального 
значения 

мяти» 

LESS 



') Операторы, имеющие ограниченное применение [только 
граммах). 


привилегированных про- 


Цикл в программе на языке SPL, организованной с помощью 
пяти операторов, может быть опущен и заменен оператором 

А-«-(1111111 >;• 


УПРАЖНЕНИЯ 

8.1. Является ли аппаратная реализация всех функций системы SYMBOL 
ее недостатком? 

8.2. Что означает выражение X [2, 3, 4], написанное на языке SPL? 

8.3. Чем является результат выполнения оператора присваивания 
А-«-Х [2, 3, 4]: скаляром или структурой? 

8.4. Фрагмент программы на языке SPL содержит группу операторов, 
оканчивающуюся оператором А [6] В. Изобразите схему структуры А по¬ 
сле выполнения этого оператора. 
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ГЛАВА 9 

АРХИТЕКТУРА ЦЕНТРАЛЬНОГО ПРОЦЕССОРА 
СИСТЕМЫ SYMBOL 

Согласно данной в гл. 3 классификации вычислительных ма- 
шин по типу архитектуры, система SYMBOL может быть отне¬ 
сена к машинам языков высокого уровня с архитектурой ти¬ 
па Б. Набор команд центрального процессора построен по прин¬ 
ципу отображения «один к одному> операторов языка SPL, 
представленных в форме обратной польской записи. Пользуясь 
терминологией, определенной в гл. 4, можно сказать, что архи¬ 
тектура центрального процессора организована с использова¬ 
нием самоопределяемых (идентифицирующих свой тип) дан¬ 
ных; дескрипторов объектов данных; средств управления под¬ 
программами и динамического управления памятью; данных, 
занимающих поля переменной длины, а также десятичной 
арифметики. 

О том, что архитектура системы SYMBOL действительно 
является архитектурой машины языка высокого уровня, сви¬ 
детельствует тот факт, что в документации описанию набора 
команд центрального процессора уделяется меньше всего вни¬ 
мания. Отсутствует какой-либо документ, содержащий набор 
команд. Материал, приведенный в данной главе, составлен по 
результатам анализа нескольких объектных программ и дис¬ 
куссий с одним из разработчиков системы. Полный набор 
команд здесь не обсуждается. Команды этого набора описыва¬ 
ются при рассмотрении примера, причем только в той степени, 
в какой это необходимо для объяснения примера. 

ПРЕДСТАВЛЕНИЕ ДАННЫХ 

Центральный процессор располагает двумя формами представ¬ 
ления скаляров и структур: внешней и внутренней. Внешняя 
форма представления скаляров и структур в памяти использу¬ 
ется при их передаче между центральным процессором и дру¬ 
гими процессорами, например транслятором и процессором ин¬ 
терфейса ввода-вывода. Для повышения эффективности обра¬ 
ботки данные могут находиться в памяти и во внутренней фор¬ 
ме. Поскольку вне центрального процессора единственным пред¬ 
ставлением данных является внешняя форма (т. е. внутренняя 
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форма представления данных не находит непосредственного 
отображения в архитектуре центрального процессора), внутрен¬ 
няя форма представления данных в данной главе не рассматри¬ 
вается; этот вопрос обсуждается в гл. 10. 

Внешней формой скаляра является строка, внутренней фор¬ 
мой—строка и числовая величина. Строка — это линейный спи¬ 
сок переменной длины из 8-битовых символов, записываемый в 
целом числе 64-битовых слов. Содержимое строки размещается 
между служебными символами начала (F5) и конца (F6) стро¬ 
ки. Символы, составляющие содержимое строки, представляют¬ 
ся в коде ASCII. Старший бит последнего байта в последнем 
слове строки должен быть единицей; это достигается помещени¬ 
ем в этот байт кода F6. Например, скаляр DOG представляет¬ 
ся в виде следующей строки: 

F5 44 4F 47 F6 XX XX F6 

где XX — условное обозначение неиспользуемого байта слова 
строки. 

Скаляр —289.143ЕМ представляется строкой, занимающей 
два слова: 

F5 2D 32 38 39 2Е 31 34 

33 45 4D F6 XX XX XX F6 

Внешняя форма структуры называется ее линейным пред¬ 
ставлением, а внутренняя — нормальным представлением. При 
использовании линейного представления структура в целом 
ограничена двумя словами, начинающимися со служебных сим¬ 
волов начала (FD) и конца (FF) группы. Каждая подгруппа 
структуры (элемент структуры, более похожий на структуру, 
чем на скаляр) ограничена двумя словами, начинающимися 
со служебных символов начала (FC) и конца (FE) подгруппы. 
Эти символы соответствуют меткам «(» и «)», обозначающим 
группу в языке SPL. Каждый скалярный элемент структуры 
записывается в виде строки. Например, структура 

<1011 <201 |202>|ABCD) 
имеет следующее линейное представление: 

FD XX XX XX XX XX XX XX 
F5 31 30 31 F6 XX XX F6 
FC XX XX XX XX XX XX XX 
F5 32 30 31 F6 XX XX F6 
F5 32 30 32 F6 XX XX F6 
FE XX XX XX XX XX XX XX 
F5 41 42 43 44 F6 XX F6 
FF XX XX XX XX XX XX XX 
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Теперь становятся очевидными причины включения в архи¬ 
тектуру системы отдельного внутреннего представления дан¬ 
ных. Например, хотя приведенное выше представление струк¬ 
туры является идеальным для процессора интерфейса ввода-вы¬ 
вода (обеспечивается формат структуры, удобной для отображе¬ 
ния на терминале), оно плохо подходит для выполнения опе¬ 
раций с индексами элементов структуры, поскольку при этом 
необходим последовательный просмотр всех слов структуры в 
процессе поиска требуемого элемента. Следовательно, целью 
использования отдельного внутреннего представления данных 
является достижение высокой эффективности их обработки 
центральным процессором. 

Размещение среди данных ограничителей строк, групп и 
подгрупп структур в первом приближении эквивалентно рас¬ 
смотренному в гл. 4 использованию тегов, определяющих типы 
данных. 

В данном случае данные используются как составная часть 
их «самоопределителя» (дескриптора), потому что значение 
данных определяет их тип, а следовательно, и операции, кото¬ 
рые могут выполняться над этими данными. Например, если 
строка состоит только из нулей и единиц, то допускаются логи¬ 
ческие, арифметические операции и операции над строками 
символов. Если содержимое строки соответствует синтаксису 
чисел, то могут выполняться арифметические операции и опе¬ 
рации, определенные над строками символов. Если же подоб¬ 
ных соответствий нет (строка не является ни последовательно¬ 
стью нулей и единиц, ни числовой последовательностью), то 
выполнение логических и арифметических операций над стро¬ 
кой не допускает сама машина (аппаратный запрет на выпол¬ 
нение) и выдается сообщение об ошибке в программе. 

ТАБЛИЦА ИМЕН 

Программа на языке SPL передается центральному процессо¬ 
ру для выполнения в виде строки объектного кода и одной или 
нескольких таблиц имен. Используемый здесь термин «строка» 
не имеет ничего общего с его трактовкой в предыдущем разде¬ 
ле. Транслятор создает одну таблицу имен для каждого блока 
исходной программы; по назначению эта таблица подобна таб¬ 
лице символических имен и таблице областей переменных в 
учебной ПЛ-машине, рассмотренной в части II книги. 

Таблица имен состоит из управляющего слова таблицы 
(block control word), за которым следуют элементы для каж¬ 
дого идентификатора блока программы (например, метки опе¬ 
ратора, имени переменной, имени процедуры). Формат табли¬ 
цы изображен на рис. 9.1, а описание назначения отдельных би- 



АРХИТЕКТУРА ЦЕНТРАЛЬНОГО ПРОЦЕССОРА СИСТЕМЫ SYMBOL 221 


тов ее первого слова (управляющего слова таблицы имен) при¬ 
ведено в табл. 9.1. Назначение большинства полей этого слова 
понятно без дополнительных пояснений. Единичное значение 
бита 4 указывает на то, что в данном блоке программы разре- 



Рис. 9.1. Формат таблицы имен, используемой в системе SYMBOL. 


шается выполнять команды, допустимые только для системных, 
программ. 

Таблица 9.1. Управляющее слово таблицы имен 


40-63 


Всегда 1 (определяет управляющее слово) 

Всегда 1 (определяет управляющее слово таблицы имен)р 
Всегда О 
Не используется 

1, если процедура привилегированная 

Всегда 1 (используется только на этапе трансляции) 

В управляющем слове содержится ссылка (биты 8—31) на- 
таблицу имен следующего блока программы — вызываемой 
процедуры 

В управляющем слове содержится ссылка (биты 40—63) на- 
таблицу имен предшествующего блока программы — вызы» 
вающей процедуры 

Адрес таблицы имен следующего блока программы 
Не используются 
1, если блок активирован 
1 при рекурсивном вызове блока 
Не используется 

Адрес таблицы имен вызывающего блока программы 
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Таблица 9.2. Управляющее слово идентификатора 




Назначение битов 


5 

6 
7 



40-63 


Всегда 1 (определяет управляющее слово) 

Обычно 0 (определяет управляющее слово идентификатора); 

1 в сочетании с единичными значениями битов 1—3‘> 
Указатель управляющего слова последнего идентификатора в 
таблице имен 1 » 

00, если имеет место обычная локальная переменная 
01, если имеет место глобальная переменная 
10, если имеет место инициализируемая локальная переменная 
или метка, процедура либо параметр 
11 — системой не воспринимается 

1, если величина, определяемая идентификатором, находится 
в строке объектного кода 

1, если имеет место структура или элемент структуры 
1, если биты 32—37 содержат дополнительные флажки 
См. табл. 9.3 

1, если разрешено использование блока ON 2 > 

Не используется 2 » 

1, если идентификатор определяет метку 2 ) 

1, если идентификатор определяет процедуру 2 ) 

1, если идентификатор определяет параметр 2 * 

1, если имеется ссылка на идентификатор в операторе ON 2 > 

Не используются 2 * 

См. табл. 9.3 


■) Если биты 0—3 равны 1111, та эти биты и остальная часть управляющего слова 
«идентификатора интерпретируются по-другому; они указывают, что величина, определяе- 
•мая идентификатором, находится в битах 0—63 этого слова. 

>) Если бит 7 равен 0, то в битах 32-39 размещается последний использованный ив- 
деке элемента структуры (см. гл. 10). 

Элементы таблицы имен состоят из двух или более слов. 
Первой частью элемента является само имя идентификатора, 
представленное в виде строки скаляров и занимающее одно или 
несколько слов. Имя используется при выдаче пользователю 
-сообщения об ошибке и при выполнении оператора OUTPUT 
DATA (отображающего на дисплее как имя идентификатора, 
так и значение определяемой им величины). Вторая часть эле¬ 
мента таблицы представляет собой управляющее слово иден¬ 
тификатора, которое по назначению подобно дескрипторам, опи¬ 
сываемым в гл. 4. В упрощенном виде идея использования этих 
управляющих слов состоит в том, что адреса операндов в объ¬ 
ектной программе указывают управляющие слова идентифика¬ 
торов, а последние указывают значения самих операндов. На¬ 
значение битов управляющего слова идентификатора поясняет¬ 
ся в табл. 9.2 и 9.3. 

Существуют два основных формата управляющего слова 
идентификатора. Если первые 4 бит имеют единичные значения. 
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Таблица 9.3. Адресные поля управляющего слова идентификатора 


Тип идентификатора 

Содержимое адресных полей 

Локальная переменная 
(биты 3—4 равны 00 
или 10) 

Биты 8—31: начальный адрес местоположения 
переменной (если она задана) 

Биты 40—63: адрес блока ON, связанного с этой 
переменной (если этот блок имеется) 

Локальная переменная 
типа структуры, не 
связанная с блоком ON 
(биты 3—4 равны 00 
или 10, бит 6 равен 1, 
бит 7 равен 0) 

Биты 8—31: начальный адрес местоположения 
переменной (если она задана) 

Биты 32—39: значение индекса последнего ис¬ 
пользованного элемента структуры 

Биты 40—63: начальный адрес последнего исполь¬ 
зованного элемента структуры 

Глобальная переменная 
(биты 3—4 равны 01) 

Биты 8—31: адрес управляющего слова иденти¬ 
фикатора соответствующей переменной в вызы¬ 
вающем блоке программы 

Биты 40—63: не используются 

Параметр (биты 7 и 36 
равны 1) 

Метка (биты 7 и 34 рав¬ 
ны 1) 

Процедура (биты 7 и 35 
равны 1) 

Биты 8—31: адрес управляющего слова иденти¬ 
фикатора или объектного кода соответствую¬ 
щего фактического параметра (если он задан) 
Биты 40—63: не используются 

Биты 8—3,1: адрес объектного кода 

Биты 40—63: адрес связанного с данной меткой 
блока ON (если этот блок имеется) 

Биты 8—31: адрес объектного кода 

Биты 40—63: адрес связанного с данной про¬ 
цедурой блока ON (если этот блок имеется) 


то величина, определяемая идентификатором, записана непо- 
средственно в управляющем слове. В противном случае управ¬ 
ляющее слово идентификатора имеет формат, описанный в 
табл. 9.2, и если в данный момент идентификатору присвоено 
значение, то биты 8—31 управляющего слова — это виртуаль¬ 
ный адрес первого слова поля, в котором находится это зна¬ 
чение. Если выполняется машинная команда, присваивающая 
идентификатору определенное значение, то центральный про¬ 
цессор сначала анализирует управляющее слово идентификато¬ 
ра и присваиваемую ему величину. Если значение бита 7 равно 
нулю (идентификатор представляет собой переменную, не свя¬ 
занную с блоком ON), а назначаемая величина — скаляр из ше¬ 
сти символов или меньше, то эта величина записывается в 
управляющее слово идентификатора. В противном случае с 
помощью контроллера памяти для величины, присваиваемой 
идентификатору, выделяется область памяти, адрес которой за¬ 
писывается в биты 8—31. Исключением являются случаи, когда 
идентификатор определяет глобальную переменную или фор- 
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мальный параметр процедуры и как следствие этого в управ¬ 
ляющее слово идентификатора помещается адрес фактической 
переменной, соответствующей данной глобальной переменной 
или формальному параметру. Например, если локальной пере¬ 
менной присвоено значение 123, то управляющее слово иденти¬ 
фикатора имеет следующий вид: 

F5 31 32 33 F6 XX XX F6 

Если же локальной переменной присваивается величина 
—123.56789, то управляющее слово идентификатора может вы¬ 
глядеть таким образом: 

80 00 77 78 XX XX XX XX 

Предполагается, что область с адресом 7778 выделена для раз¬ 
мещения значения переменной. 

Для иллюстрации процесса формирования транслятором 
таблиц имен и строки объектного кода воспользуемся приводи¬ 
мой ниже программой 

В <-4; 

1 <— 1; 

1: IF I LTE В THEN 
А[ I ]«—1; 

I «-І + 1; 

GO ТО L; 

END 

•С <— В + В * В; 

•CALL ZZZ(B); 

*А[В] «- С; 

PROCEDURE ZZZ (М); 

GLOBAL С; 

С М + М; 

END 

’ На рис. 9.2 показаны таблицы имен, полученные в резуль¬ 
тате трансляции программы. Числа, расположенные слева от 
каждого элемента таблиц, определяют его виртуальный адрес. 
Хотя таблица имен воспринимается транслятором и централь- 
дым процессором как список, записанный в смежных областях 
памяти, элементы таблицы располагаются в виртуальной памя¬ 
ти не обязательно последовательно. Этот факт не очевиден 
только для контроллера памяти из-за метода, посредством кото¬ 
рого контроллер отображает списковое представление структу¬ 
ры реальной памяти в последовательную виртуальную память. 
.(Этот метод рассматривается в гл. 10.) 

Поскольку атрибуты и размеры переменных могут изменять¬ 
ся динамически, транслятор не резервирует память для их раз- 
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мещения. Следовательно, биты 8—31 управляющего слова иден¬ 
тификатора для всех локальных переменных и параметров пер¬ 
воначально имеют нулевые значения. Идентификаторы L и 
ZZZ относятся к метке и процедуре соответственно; таким об- 


виртцамный 

2220 

2221 

2222 

2223 

2224 

2225 
' 2226 

2227 

22-70 

2271 

2272 

2273 

2274 


С6 00 22 88 00 00 00 00 


42 XX XX XX XX XX XX XX 


4С XX XX XX XX XX XX XX 


80 00 00 00 XX XX XX XX 


49 XX XX XX XX XX XX XX 


80 00 00 00 XX XX XX XX 


91 00 30 28 20 XX XX XX 


41 XX XX XX XX XX XX XX 


80 00 00 00 XX XX XX XX 


43 XX XX XX XX XX XX XX 


80 00 00 00 XX XX XX XX 


5А 5А 5А XX XX XX XX XX 


В1 00 30 72 10 XX XX XX 


2288 

2289 

228А 

228В 

228С 


С5 00 00 00 00 00 22 20 


4D XX XX XX XX XX XX XX 


91 00 00 00 08 XX XX XX 


43 XX XX XX XX XX XX XX 


АЗ 00 22 72 XX XX XX XX 


Рис. 9.2. Таблицы имен 
для рассматриваемой 
программы. 


пазом их управляющее слово в таблице имен указывает на 
определенную точку в строке объектного кода. (Объектный код 
для данной программы приводится в Объ¬ 

ектный код для метки L начинается с адреса 3028, а для про 
цедуры ZZZ-c адреса 3072.) Заметим также, что переменная 
С описана как глобальная во второй таблице и «ен, следова 
тельно, управляющее слово идентификатора для переменной С 


15-283 
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в этой таблице адресует управляющее слово идентификатора С 
в таблице имен внешней процедуры. 

объектный код программы 

Набор команд центрального процессора системы SYMBOL явля¬ 
ется стеко-ориентированным и подобен набору команд учеб¬ 
ной ПЛ-машины. Принципиальные различия между наборами 
команд этих двух систем заключаются, во-первых, в способе 
адресации операндов: вместо использования адресации на лек¬ 
сическом уровне команды системы SYMBOL адресуют свои 
операнды с помощью управляющего слова идентификатора; во- 
вторых, набор команд системы SYMBOL менее эффективно ис¬ 
пользует память, и, в-третьих, в системе SYMBOL отсутствуют 
операции над массивами (за исключением операции присвое¬ 
ния значения). 

Каждая команда SYMBOL начинается с 8-битового кода 
операции. В зависимости от кода операции оставшаяся часть 
команды имеет один из следующих четырех форматов: 

1) операнд отсутствует, длина команды составляет 32 бит; 
последние 24 бит не используются; 

2) операнд представляет собой данные; длина команды рав¬ 
на 32 бит; последние 24 бит — виртуальный адрес управляюще¬ 
го слова идентификатора; 

3) операнд представляет собой команду; длина команды рав¬ 
на 32 бит; последние 24 бит — виртуальный адрес команды; 

4) операнд представляет собой литерал; длина команды — 
переменная, равная целому числу слов; код операции распола¬ 
гается на границе слова; код операции — служебный символ 
начала строки, начала структуры или начала подгруппы струк¬ 
туры; операнд — оставшаяся часть строки или линейного пред¬ 
ставления структуры. 

Обычно команды размещаются по две в одном слове памя¬ 
ти; при этом код операции команды должен находиться на гра¬ 
нице слова или полуслова. Команды, которые расположены не 
на границе слова, — неадресуемы. Для того чтобы к подобной 
команде могла адресоваться другая команда, первую необходи¬ 
мо выровнять на границу слова. Это осуществляется включени¬ 
ем в соответствующее место программы команд типа NOP (N0 
OPERATION — НЕТ ОПЕРАЦИИ). Этот же прием применяется 
для компенсации дефектов конструкции транслятора, обуслов¬ 
ливающих расположение команд одного типа на границе сло¬ 
ва, а другого типа — вне таких границ. 

В качестве примера рассмотрим объектный код приведенной 
выше программы на языке SPL вместе с таблицами имен, пред¬ 
ставленными на рис. 9j2. Подобно команде LINE учебной 
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ПЛ-машины, объектный код системы SYMBOL указывает со¬ 
ответствующие номера операторов исходной программы, кото¬ 
рые могут быть использованы для отладки последней. В данном 
случае это достигается хранением исходной программы в па¬ 
мяти во время выполнения ее объектного кода. На рис. 9.3 по¬ 
казано, как представляется исходная программа в памяти ма¬ 
шины. л 


Виртуальный Содержимое 

адрес слова 


Виртуальный Содержимое 

адрес слова 


1020 В— 4; I*- 

1021 1; L; I:F 

1022 I LTE В 

1023 THEN А I 

1024 . —I; Ь-1 

1025 +1; GO Т 

1026 О L; END 

1027 С* В+В*В; 


CALL ZZZ 
(В); А В 
-С; PRO 
CEDUREZ 
ZZ(M); G 
LOBAL С; 
C+-M+M; E 
ND 


Рис. 9.3. Представление исходной программы в памяти. 

3020 00 XXXXXX Команда НЕТ ОПЕРАЦИИ 

90 002220 Команда BLOCK 

Команда NTP для переменной В 
Команда НЕТ ОПЕРАЦИИ 
Строка данных (число 4) 


3029 

302А 


302С 

302D 


хххххх 

34F6XX 

XXXXF6 

ХХХХХХ 

ХХХХХХ 

001020 

002224 

31F6XX 

XXXXF6 

ХХХХХХ 

ХХХХХХ 

001021 

хххххх 

хххххх 

002220 

002224 

002222 

ХХХХХХ 

003067 

002270 

002222 

ХХХХХХ 

ХХХХХХ 

31F6XX 

XXXXF6 

ХХХХХХ 

хххххх 


Команда присвоения значения 

ѵ -- а 0пе р ат0 р а исходной программы 

-я оператора исходной программы 


Команда Кс~^ 

Команда указ-..,__ 

Команда NTP для переменной I 
Строка данных (число 1) 

Команда присвоения значения 

Команда конца оператора исходной программы 

Команда указания оператора исходной программы 

Команда НЕТ ОПЕРАЦИИ 

Команда НЕТ ОПЕРАЦИИ 

Команда NTP для переменной I 
Команда NTP для переменной В 
Команда сравнения на «меньше» или «равно» 
Переход, если ЛОЖНО 

Команда NTP для идентификатора структуры А 
Команда NTP для переменной I 
Команда поиска элемента структуры 
Команда НЕТ ОПЕРАЦИИ 
Строка данных (число 1) 


Рис. 9.4. Первая часть объектного кода программы. 


Первая часть объектной программы приведена на рис. 9.4. 
В первой колонке слева указан виртуальный адрес каждого сло¬ 
ва. Вторая и третья колонки содержат код операции и адреса 
операндов. Как и ранее, X обозначает неиспользуемые байты 
команды. Четвертая колонка содержит комментарий к каждой 
команде. Последовательность машинных команд не обязательно 
записывается в смежных ячейках виртуальной памяти. Это яв¬ 
ляется очевидным только для контроллера памяти; центрально- 
15* 




228 глава » 


му процессору команды представляются расположенными в па¬ 
мяти последовательно в виде линейного списка. 

Первой выполняемой командой программы является команда 
BLOCK. Транслятор всегда генерирует команду BLOCK во вто¬ 
рой части слова, располагая перед ней команду НЕТ ОПЕРА¬ 
ЦИИ. Команда BLOCK указывает адрес (002220) управляю¬ 
щего слова таблицы имен. 

Следующие пять команд соответствуют оператору исходной 
программы В-*-4. Первая из них — команда NTP. Идентифика¬ 
торы, появляющиеся в тексте исходной программы, транслиру¬ 
ются в команду NTP, указывающую положение управляющего 
слова данного идентификатора в таблице имен. Интерпретация 
команды зависит от атрибутов идентификатора, находящихся 
в таблице имен. Например, если идентификатор ссылается на 
переменную, то NTP — команда загрузки данных в стек; если на 
процедуру, то NTP — команда вызова процедуры. В данном слу¬ 
чае по команде NTP в стек центрального процессора загружа¬ 
ется слово связи. Слово связи содержит адрес (002222) управ¬ 
ляющего слова идентификатора В, а также байт, идентифици¬ 
рующий этот элемент стека (в данном случае величину Е0, 
означающую «слово связи для простой переменной»). 

Заметим, что следующая выполняемая команда имеет фор¬ 
мат строки данных, описанный в начале главы. (Команде пред¬ 
шествует команда NOP, обеспечивающая выравнивание строки 
данных на границу слова.) Любая строка данных, встречающая¬ 
ся в потоке машинных команд, загружается в стек. 

Команда ASSIGN (адрес 3023) выделяет память для вели¬ 
чины, находящейся в данный момент на вершине стека, моди¬ 
фицирует управляющее слово идентификатора, адресуемое сле¬ 
дующим элементом стека (так что оно теперь указывает выде¬ 
ленную область памяти), и удаляет элемент, находящийся на 
вершине стека. В данном случае память выделена не будет, по¬ 
скольку величина переменной (число 4) достаточно мала и мо¬ 
жет быть записана непосредственно в управляющее слово иден¬ 
тификатора по адресу 002222. Команда END-OF-STATEMENT 
производит очистку стека и разрешает вызов любого блока QN, 
ожидающего в данный момент своего выполнения. Команда 
SOURCE-POINTER указывает адрес конца соответствующего 
оператора исходной программы; она воспринимается как коман¬ 
да НЕТ ОПЕРАЦИИ. 

Команды, расположенные начиная со второй половины сло¬ 
ва с адресом 3024 до слова с адресом 3027, полностью подобны 
предшествующим и относятся к оператору Іч-1. 

^Следующая команда BLOCK обусловлена наличием в исход¬ 
ной программе метки L. Подобная команда необходима для 
каждой метки исходной программы, поскольку дает машине 




АРХИТЕКТУРА ЦЕНТРАЛЬНОГО ПРОЦЕССОРА СИСТЕМЫ SYMBOL 229 


возможность «настроиться» на ситуацию, при которой на метку 
ссылается оператор GO ТО, расположенный в другом (внутрен¬ 
нем) блоке. Заметим, что управляющее слово идентификатора 
L в таблице имен указывает слово с адресом 3028. 

Следующие три команды вычисляют логическую величину, 
соответствующую условию, указанному в операторе IF, и поме¬ 
щают ее на вершину стека. Если эта величина имеет значение 
«ложно», то управление передается на выполнение объектного 
кода, задаваемого текстом исходной программы, следующим за 
ELSE (предложение ELSE отсутствует в языке SPL, поэтому 
управление передается на выполнение объектного кода следу¬ 
ющего оператора). 

Команды, расположенные начиная с адреса 302В, соответ¬ 
ствуют оператору А[І]ч-1, который с помощью индекса ссыла¬ 
ется на элемент структуры. Команда SUBSCRIPT преобразует 
величину, находящуюся на вершине стека в целое число, и осу¬ 
ществляет поиск в стеке первого слова для структуры, заменяя 
эту величину и расположенные над ней величины (значения 
индекса или индексов) на адрес элемента, к которому произ¬ 
водится обращение. (Если используется множественное индек¬ 
сирование, то после команд NTP или STRING должна быть сге¬ 
нерирована команда INTEGERIZE для преобразования всех 
индексов, кроме последнего, в целые величины.) Поскольку к 
этому моменту величина А[І] еще не известна, и процессор еще 
не знает, какой объем памяти следует выделить для данного 
элемента структуры, рассматриваемая операция — индексирова¬ 
ние— задерживается до выполнения команды ASSIGN, распо¬ 
ложенной по адресу 302Е. 

Объектный код оператора І-<-І+ 1 состоит из восьми команд, 
расположенных в памяти, начиная со второй половины слова 
с адресом 302F (рис. 9.5). Команда ADD выполняет проверку 
формата числовых операндов и инициирует сообщение об ошиб¬ 
ке, если хотя бы один операнд является не числовым. И опять- 
таки вследствие особенностей построения транслятора в объ¬ 
ектный код программы включается команда НЕТ ОПЕРАЦИИ. 
Команда GO ТО, расположенная по адресу 3065, соответствует 
оператору GO ТО исходной программы. В этот момент адрес 
управляющего слова идентификатора для метки L находится в 
стеке; само управляющее слово содержит адрес 3028. 

Команды, расположенные по адресам 3067—306А, соответ¬ 
ствуют оператору 0-В+В*В и выполняют указанные опера¬ 
ции непосредственно. Команда НЕТ ОПЕРАЦИИ находится по 
адресу 3066, поскольку передача управления (в обход отсутст¬ 
вующего предложения ELSE оператора IF) осуществляется 
команде NTP для переменной С. Все команды, выполняющие 
арифметические операции, проверяют, корректно ли заданы 




Команда NTP для идентификатора Z2 
Команда передачи параметра 
Команда конца оператора исходной программы 


Рис. 9.5. Вторая часть объектного кода программы. 


операнды и не превышает ли результат операции предельно до¬ 
пустимого значения. В данном случае подобных ситуаций не 
возникает. 

Последние три команды (рис. 9.5) реализуют оператор 
CALL. Команда NTP для идентификатора ZZZ интерпретирует¬ 
ся как вызов процедуры. При этом процессор осуществляет 
поиск команд с параметрами процедуры (которые загружаются 
в стек) и команд пересылки (которые выполняются). При об¬ 
наружении команды, соответствующей точке возврата, устанав¬ 
ливается связь с таблицей имен для этой новой процедуры (по¬ 
средством команды BLOCK, с которой она начинается), коман¬ 
ды с параметрами извлекаются из стека и используются для 
присвоения начальных значений управляющим словам иденти¬ 
фикаторов формальных параметров вызываемой процедуры. 
Вход в блок осуществляется загрузкой в стек информации о 
состоянии вызывающего модуля, получения памяти для нового 
стека и установления связи нового стека с предыдущим. 

Поскольку передача процедуре фактических параметров 
осуществляется по имени (а не путем передачи значений этих 
параметров) и в связи с тем, что фактические параметры мо¬ 
гут представлять собой выражения, включающие знаки опе¬ 
раций, значения параметров процедуры не могут быть опреде¬ 
лены в момент ее вызова. Вместо этого в управляющие слова 
идентификаторов фактических параметров помещается ссылка 
на одну или более команд объектной программы, которые вы¬ 
полняются при каждом обращении к этим параметрам. Однако 
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в этом случае фактический параметр является переменной; по¬ 
этому управляющее слово идентификатора формального пара¬ 
метра модифицируется таким образом, чтобы указывать на 
управляющее слово идентификатора фактического параметра. 
Так, управляющее слово идентификатора, расположенное по 
адресу 2289 (рис. 9.2), будет указывать управляющее слово 
идентификатора, находящееся по адресу 002222, Пример, объ¬ 
ясняющий механизм передачи процедуре фактических парамет¬ 
ров (представляющих собой выражения) по имени, приводится 
в следующем разделе. 


306D 

306Е 

306F 


XXXXXX 

002272 

хххххх 

хххххх 

хххххх 

00102А 

003078 

хххххх 


00228А 

хххххх 

хххххх 


Команда указания оператора исходной программы 

Команда NTP для переменной А 

Команда NTP для переменной В 

Команда поиска элемента структуры 

Команда NTP для переменной С 

Команда присвоения значения 

Команда конца оператора исходной программы 

Команда НЕТ ОПЕРАЦИИ 

Команда указания оператора исходной программы 
Команда перехода 
Команда НЕТ ОПЕРАЦИИ 
Команда BLOCK 

Команда указания оператора исходной программы 

Команда NTP для переменной С 

Команда NTP для переменной М 

Команда NTP для переменной М 

Команда сложения 

Команда присвоения значения 

Команда конца оператора исходной программы 

Команда НЕТ ОПЕРАЦИИ 

Команда указания оператора исходной программы 
Команда BLOCK 
Команда BLOCK 


Рис. 9.6. Третья часть объектного кода программы. 


Согласно рис. 9.6, управление теперь передается по адресу 
3072 (величина, находящаяся в управляющем слове идентифи¬ 
катора ZZZ). При выполнении команды NTP, расположенной 
по адресу 3073, машина выясняет, что переменная С — глобаль¬ 
ная, и поэтому просмотр цепочки управляющих слов идентифи¬ 
катора, на которую указывает управляющее слово, осуществ¬ 
ляется в обратном порядке. Поиск продолжается до тех пор, по¬ 
ка не встретится управляющее слово, не относящееся к глобаль¬ 
ной переменной. Как только такое слово найдено, оно загружа¬ 
ется в стек. При выполнении команд, содержащихся в слове с 
адресом 3074, машина выясняет, что определяемые этими 
командами управляющие слова идентификаторов являются 
формальными параметрами процедуры, и загружает адрес со¬ 
ответствующего управляющего слова идентификатора фактиче¬ 
ского параметра в стек. Стек теперь содержит два указателя 
управляющего слова идентификатора В и указатель управля¬ 
ющего слова идентификатора С — переменная С определена 
во внешней процедуре. 

Команда END-BLOCK, расположенная в слове с адресом 





Таблица 9.4. Сопоставление размеров программ 


Вычислительная система 

Количество 

выполняв- 

Размер объ¬ 
ектного ко¬ 
да, байт 

Общий раз- 
Ме £ы ПР б°а Р йГ 

Система SYMBOL 

81 

324 

396 

Учебная ПЛ-машина 

62 

96 

369 

Система 370 

зозі) 

564 

5912 

Система 370*> 

112 1 ) 

360 

5496 


') И еще 90 000 команд, выделяющих в начале программы память для организация 
вызова подпрограмм и возврата из них. 

s ) Вариант программы на языке ШІ/1 без оператора ALLOCATE и контроля индек¬ 
сирования массивов. 


3077, завершает выполнение процедуры. При этом текущее со¬ 
держимое стека уничтожается, восстанавливается информация, 
сохраняемая в предыдущем стеке, и осуществляется возврат 
управления по адресу 306D. Заметим, что адреса локальных пе¬ 
ременных в таблице имен, относящейся к завершенной процеду¬ 
ре, не изменяются, и им не присваиваются нулевые значения; 
в этом смысле локальные переменные являются статичными. 

Команды, находящиеся по адресам 306D —3070, присваива¬ 
ют значение элементу структуры Аі[В], после чего управление 
передается в обход тела внутренней процедуры и программа 
завершается. 

В табл. 9.4 приводится сравнение характеристик рассмотрен¬ 
ной объектной программы с объектными программами для эк¬ 
вивалентных программ, написанных на учебном языке ПЛ и 
языке ПЛ/1 Системы 370. Записываемая в память копия исход¬ 
ной программы, составленной на языке SPL, не входит в чис¬ 
ловые величины таблицы, относящиеся к системе SYMBOL, для 
достижения наибольшей точности проводимого сравнения. При¬ 
чиной более низкой эффективности системы SYMBOL по срав¬ 
нению с учебной ПЛ-машиной является нерациональное кон¬ 
струирование ее набора команд. Так, 8-битовая команда до¬ 
полняется 24 неиспользуемыми битами, производится выравни¬ 
вание генерируемых транслятором команд при размещении их 
в памяти. 

ПЕРЕДАЧА ФАКТИЧЕСКИХ ПАРАМЕТРОВ 
ВЫЗЫВАЕМОЙ процедуре 

Поскольку, согласно языку SPL, передача фактических пара¬ 
метров вызываемой процедуре осуществляется путем указания 
их имен, формальным параметрам процедуры не могут быть 
присвоены исходные значения во время ее вызова. Поэтому при 
каждом использовании параметра его значение подлежит опре¬ 
делению. Так, оператор языка SPL 
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CALL COST(1+K,20*M) 


формирует фрагмент объектной программы, представленный 
на рис. 9.7, причем символы ZZZZZZ обозначают местоположе¬ 
ние ссылок на таблицу, содержащую имена подлежащих оп¬ 
ределению величин. 

DO ZZZZZZ Команда NTP для идентификатора COST 

D7 001126 Команда перехода 

DO ZZZZZZ Команда NTP для переменной I 

DO ZZZZZZ Команда NTP для переменной К 

АВ ХХХХХХ Команда сложения 

D8 ХХХХХХ Команда окончания вычисления параметра 

F5 3230F6 Строка данных (число 20) 

XX XXXXF6 

DO ZZZZZZ Команда NTP для переменной М 

АА ХХХХХХ Команда умножения 

D8 ХХХХХХ Команда окончания вычисления параметра 

00 ХХХХХХ Команда НЕТ ОПЕРАЦИИ 

D5 001123 Команда присвоения параметру значения выражения, его 

представляющего 

D5 001121 Команда присвоения параметру значения выражения, его 

представляющего 

BB ХХХХХХ Команда конца оператора исходной программы 


Рис. 9.7. Объектный код фрагмента программы, передающего 
параметры по имени. 


Команды INDIRECT-PARAMETER обеспечивают присвоение 
исходных значений формальных параметров в таблице имен 
для процедуры COST таким образом, чтобы эти параметры 
указывали не на управляющие слова идентификаторов факти¬ 
ческих параметров, а на строки объектного кода выражений, 
вычисляющих значения фактических параметров. Когда на такой 
параметр производится ссылка в вызываемой процедуре, соот¬ 
ветствующая строка объектного кода выполняется до тех пор, 
пока не встретится команда PARAMETER-RETURN. Например, 
всякий раз, когда в процедуре COST для первого параметра 
необходимо выполнение команды NTP, происходит выполне¬ 
ние команд NTP I, NTP К и ADD. 

УПРАЖНЕНИЯ 

9.1. Одной из внутренних форм представления скаляров является число¬ 
вое представление. Хотя этот вопрос еще не обсуждали, сделайте предполо¬ 
жение о том, на что должно быть похоже такое представление. 

9.2. Каким является линейное представление структуры 

-<0000000| II М1Ш>? 

9.3. Опишите содержимое управляющего слова идентификатора, располо¬ 
женного по адресу 2224, после выполнения команды, находящейся по адре¬ 
су 3026, для программы, приведенной на рис. 9.4. 

9.4. Опишите содержимое управляющего слова идентификатора, располо¬ 
женного по адресу 2224, если переменной I было присвоено значение 
1234.5678. 

9.5. Из какого управляющего слова идентификатора будет получена ин¬ 
формация о величине М при выполнении объектного кода, соответствующего 
оператору С-»- М+М? Содержимое какого управляющего слова идентифика¬ 
тора изменит этот оператор? 




Т Л А В А ІО 

ВНУТРЕННЯЯ СТРУКТУРА И ВЗАИМОСВЯЗЬ 
ПРОЦЕССОРОВ СИСТЕМЫ SYMBOL 

По содержанию эта глава, посвященная практической реализа¬ 
ции процессоров системы SYMBOL и их взаимосвязи в процес¬ 
се функционирования, является как бы отступлением от основ¬ 
ной темы книги — анализа архитектуры ЭВМ. Целесообраз¬ 
ность рассмотрения данного предмета обусловлена двумя обсто¬ 
ятельствами. Во-первых, архитектура центрального процессора 
вычислительной системы в существенной мере определяет реа¬ 
лизацию системы в целом, и в частности средства управления 
памятью, а следовательно, заслуживает первостепенного вни¬ 
мания. Во-вторых, поскольку одним из уникальных свойств си¬ 
стемы SYMBOL является распределенная мультипроцессорная 
обработка особого типа с функциональной ориентацией отдель¬ 
ных процессоров, проведение более полного анализа организа¬ 
ции системы является оправданным. 

ОСНОВНАЯ ШИНА 

Так как основная шина служит средством взаимосвязи всех 
процессоров системы (рис. 8.1), первым шагом на пути изуче¬ 
ния внутреннего функционирования системы SYMBOL долж¬ 
но быть ознакомление с назначением и техникой использова¬ 
ния этой шины. По основной шине передаются следующие сиг¬ 
налы: 

1) запросы на обращение к памяти от процессора к контрол¬ 
леру памяти (цикл запроса на обращение к памяти); 

2) результаты обращения к памяти из контроллера памяти 
к процессору (цикл передачи ответа на обращение к памяти); 

3) сигнал управления от процессора к супервизору (цикл 
обмена сигналами управления); 

4) сигнал управления от супервизора к процессору (цикл 
обмена сигналами управления); 

5) данные между процессорами, входящими в состав цент¬ 
рального процессора (так называемый неявный цикл). 

Основная шина состоит из 111 линий. Назначение линий ука¬ 
зано в табл. 10.1. Шина используется в соответствии с системой 
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Таблица 10.1. Назначение линий основной шины 


линий 

Обозначение 

линий 

Назначенне 

1 


He используется 

2—7 

МС 

Функция обращения к контроллеру памяти и ко¬ 
ды завершения 

8—12 

мт 

Номер терминала 

13—36 

МА 

Адрес памяти 

37—100 

MD 

Данные 

101 


Сброс системы 

102 


Тактовые импульсы 

103 

МР1 

Запрос обращения к памяти супервизора системы 
Запрос обращения к памяти процессора интер¬ 
фейса ввода-вывода 

104 

MP2 

105 

MP3 

Запрос обращения к памяти центрального процес- 

106 

MP4 

Запрос обращения к памяти транслятора 

107 

MP5 

Указание на то, что следующим будет цикл пе¬ 
редачи ответа на обращение к памяти 

108 

MP6 

Запрос цикла обмена сигналами управления 

109 

MP7 

Указание, что контроллер памяти свободен 

ПО 

MP8 

Запрос обращения к памяти регенератора па¬ 
мяти 

111 


Не используется 


приоритетов; линиями, обладающими определенными приори¬ 
тетами, являются МР1—МР8. Наивысший приоритет присвоен 
линии МР1, самый низкий — линии МР8. Когда процессору 
нужна основная шина, он запрашивает одну из линий МР1— 
МР8. Например, если центральному процессору необходимо 
обратиться к контроллеру памяти, он активирует линию 
MP3, а если необходима связь с супервизором — линию МР6. 
Если в данный момент ни одна из линий, обладающих приори¬ 
тетом, не занята, то шина используется процессором в течение 
следующего цикла — периода между тактовыми импульсами 
устройства синхронизации. Если же нужная линия, имеющая 
приоритет, занята, то процессор пропустит один цикл и повто¬ 
рит запрос. 

Предположим, что центральному процессору требуется пере¬ 
слать слово данных в память. Для этого он возбуждает линию 
MP3 и проверяет состояние линий МР1, МР2 и МР7. Если ли¬ 
нии МР1 и МР2 неактивны, а на линии МР7 сигнал установ¬ 
лен (это указывает на то, что контроллер памяти не занят об¬ 
работкой другого запроса), то центральный процессор передаст 
адрес памяти на линии МА, данные — на линии MD, код тре¬ 
буемой операции обращения к памяти на линии МС, иденти¬ 
фикатор терминала или пользователя (для которого выполнял 
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ется обращение к памяти) на линии МТ. Затем контроллер па¬ 
мяти осуществляет сброс сигнала на линии МР7 (линия пере¬ 
стает быть активной) и продолжает обрабатывать запрос. В это 
время шина может использоваться для передачи данных между 
процессорами, но не для обращения к памяти. По окончании 
обработки запроса контроллер памяти устанавливает сигнал 
на линии МР5. Во время следующего цикла контроллер памя¬ 
ти передает на линии МС код завершения, и, если в ответ на 
обращение к памяти возвращается адрес соответствующей об¬ 
ласти (что является обычным для систем со списковой органи¬ 
зацией памяти), этот адрес поступает на линии МА. В это 
>время центральный процессор проверяет состояние линии МР5. 
‘Обнаружив сигнал на этой линии, процессор получает тем са¬ 
мым информацию о том, что во время следующего цикла в ши¬ 
ну будут переданы результаты обработки запроса контролле¬ 
ром памяти. 

Если необходимо передать сигнал управления от процессора 
к супервизору или от супервизора к одному или нескольким 
процессорам, то активируется линия МР6, и если линии 
МР1—МР5 неактивны, то управляющая информация переда¬ 
ется на линии MD. Такой режим работы линии называется 
циклом обмена сигналами управления. Во время этого режима 
линию потенциально могут использовать все процессоры. Такая 
возможность обеспечивается за счет разделения во время этого 
цикла отдельных линий из группы линий MD между различны¬ 
ми группами устройств. Например, во время цикла обмена сиг¬ 
налами управления по линиям 37—40 передаются сигналы от 
супервизора к центральному процессору, по линиям 41—44 —от 
центрального процессора к супервизору, по линиям 45—48 — от 
супервизора к транслятору, по линиям 49—52 —от транслятора 
к супервизору и т. д. 

Как упоминалось выше, линии МС используются во время 
цикла запроса на обращение к памяти для передачи функции 
обращения к контроллеру памяти. Сигналы на линиях 2—5 оп¬ 
ределяют одну из 14 возможных функций обращения к логиче¬ 
ской памяти, которая должна быть реализована, а сигналы на 
линиях 6—7 указывают, к какому списку страниц виртуальной 
памяти пользователя относится данный запрос (последние из 
упомянутых сигналов позволяют минимизировать фрагмента¬ 
цию памяти; использование обеих этих групп линий описыва¬ 
ется в следующем разделе). Во время цикла передачи ответа 
на обращение к памяти контроллер памяти передает на линии 
МС код завершения. Например, наличие кода 000011 свиде¬ 
тельствует об успешном выполнении запроса, кода 000001—об 
отсутствии требуемой страницы памяти, код 100000 указывает 
на сбой оборудования при обращёнии к памяти. 
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УПРАВЛЕНИЕ ПАМЯТЬЮ 

Наиболее существенной особенностью системы SYMBOL явля¬ 
ется, по-видимому, использование высокоорганизованной, гиб¬ 
кой и динамичной системы управления памятью. Как отмечено 
в гл. 8, эта система реализуется главным образом в виде конт¬ 
роллера памяти и в меньшей степени как регенератор памяти и 
супервизор. 

Системе SYMBOL присуща иерархическая организация па¬ 
мяти, верхний уровень которой занимает так называемая логи¬ 
ческая память. Такая организация позволяет рассматривать ре¬ 
альную память как неограниченное число линейных списков не¬ 
ограниченной длины или строк, состоящих из 64-битовых слов. 
Следующей в иерархии является виртуальная память, пред¬ 
ставляющая реальную память как непрерывное адресное про¬ 
странство (вектор) из 16 777 216 64-битовых слов. Функции 
контроллера памяти сводятся к отображению логической памя¬ 
ти в виртуальную память. Последняя разделена на страницы, 
каждая из которых содержит 256 слов (2048 байт или симво¬ 
лов). Одна из функций супервизора состоит в отображении 
страниц виртуальной памяти в память третьего уровня, т. е. в 
основную память, являющуюся физически реальной. 

ЛОГИЧЕСКАЯ ПАМЯТЬ 

Логическая память — это такое представление памяти, которое 
возникает у процессоров системы с помощью контроллера па¬ 
мяти. Лучшим способом описания структуры логической памяти 
является определение 14 функций обращения к памяти, реали¬ 
зуемых контроллером памяти (табл. 10.2). 

Согласно гл. 9, такие элементы объектной программы, как 
таблица имен и строка объектного кода, не обязательно долж¬ 
ны записываться в смежных областях виртуальной памяти, од¬ 
нако об этом известно только контроллеру памяти. В этом 
можно убедиться, рассмотрев операции, описанные в табл. 10.2. 
Например, при генерировании таблицы имен транслятор посы¬ 
лает запрос типа AG контроллеру памяти. Последний возвра¬ 
щает адрес первого слова новой строки. Когда транслятор го¬ 
тов к записи в память управляющего слова таблицы имен (пер¬ 
вого слова), он запрашивает выполнение операции SA и пере¬ 
дает контроллеру памяти адрес, полученный в результате пред¬ 
шествующей операции AG, и данные, подлежащие записи в па¬ 
мять. После обработки данного запроса контроллер памяти пе¬ 
редает транслятору адрес следующего слова строки. Для про¬ 
должения записи в память таблицы имен транслятор посылает 
запросы типа SA, передавая в контроллер адрес, полученный 
после выполнения предыдущей операции SA. 
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Таблица 10.2. Операции контроллера памяти 


Название 

операции 

Назначение и выполняемая функция 

AG 

Используется для начала новой строки 

Возвращает адрес первого слова строки 

SA 

Используется для записи данных в строку 

Записывает указанные данные по указанному адресу и воз¬ 
вращает адрес следующего слова строки 

FF 

Используется для просмотра строки 

Возвращает величину, находящуюся по указанному адресу, 
и адрес следующего слова строки 

FR 

Используется для просмотра строки в обратном направлении 
Возвращает величину, находящуюся по указанному адресу, 
и адрес предшествующего слова строки 

FL 

Используется для просмотра строки 

Возвращает значение и адрес слова, находящегося за ука¬ 
занным словом строки 

IG 

Используется для включения строки в другую строку 

SI 

Используется для включения строки в другую строку 

SO 

Используется для записи данных в строку 

Запись указанной величины по указанному адресу 

DS 

Используется для удаления строки 

DE 

Используется для удаления части строки 

Изымает все слова строки, расположенные после указанно¬ 
го адреса 

FD 

Используется для выборки содержимого слова, находящего¬ 
ся по указанному адресу в основной (реальной) памяти 

SD 

Используется для записи данных по указанному адресу ос¬ 
новной реальной памяти 

DL 

Используется регенератором памяти для добавления списка 
страниц виртуальной памяти к списку свободных страниц 

RG 

Используется регенератором памяти для передачи группы 
слов из списка групп с «информационным мусором» в список 
доступных для распределения групп слов 


Другим примером является посылка центральным процессо¬ 
ром контроллеру памяти запросов типа FF для выборки машин¬ 
ных команд. В ответ на каждый такой запрос контроллер па¬ 
мяти производит возврат 64-битового слова (содержащего обыч¬ 
но две команды) и адреса следующей команды. Если в теку¬ 
щей команде содержится адрес операнда, то центральный про¬ 
цессор использует этот адрес при выдаче запроса типа FF дл» 
получения управляющего слова идентификатора операнда. 

Поскольку адреса, передаваемые контроллеру памяти, на 
предыдущем этапе им же формируются и передаются произвол 
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дящим обращение к памяти процессорам, последним не изве¬ 
стно, что слова строки логической памяти могут располагаться 
и не в смежных областях виртуальной памяти. В действительно¬ 
сти процессоры не «рассматривают» адреса данных в традици¬ 
онном смысле; для них адрес — это просто 24-битовое имя не¬ 
которой величины, хранимой в памяти. 


ВИРТУАЛЬНАЯ ПАМЯТЬ 

Функцией контроллера памяти является отображение логиче¬ 
ской памяти в едином виртуальном адресном пространстве 
объемом 16 млн. слов. Для того чтобы понять, как осуществля¬ 
ется этот сравнительно сложный процесс, рассмотрим вначале 
полную структуру виртуальной памяти, изображенную на 
рис. 10.1. 

Страница 1 физической памяти используется для размеще¬ 
ния системных таблиц. Страницы 2—4 содержат информацию 
о каждом пользователе системы. В страницах 5 и 6 находятся 
буферы ввода-вывода, используемые контроллером каналов вво¬ 
да-вывода. Оставшиеся страницы образуют адресное простран¬ 
ство, предназначенное контроллеру памяти для организации 
логической памяти. Как показано на рис. 10.1, вследствие при¬ 
менения логической памяти нет необходимости в выделении 
каждому пользователю непрерывной области виртуальной па¬ 
мяти. Фактически страницы памяти, выделяемые разным поль¬ 
зователям, размещаются в виртуальной памяти произвольным 
образом, однако разным пользователям никогда не предостав¬ 
ляется память на одной и той же странице. 

Формат страницы последней области виртуальной памяти 
(применяемой для организации логической памяти пользовате¬ 
лей) показан на рис. 10.2. Первые четыре слова используются 


Таблица 10.3. Описание формата слова связи группы слов страницы 


Номера 


Назначение битов 


Поле «быстрого поиска» 

Адрес следующей группы строки 

Указание наличия содержимого в поле «быстрого поиска» 
Указание наличия ссылки на следующую группу 
Указание наличия ссылки на предыдущую группу 
Указание наличия свободного пространства памяти 
Указание на то, что это последняя группа строки 
Указание на то, что одно из слов группы — адрес 
Не используются 

Адрес предыдущей группы строки 
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как заголовок страницы, предназначенный прежде всего для 
организации связи между страницами, входящими в состав раз¬ 
личных списков страниц. Следующими 28 словами являются 
слова связи групп. Они служат для обеспечения представления 
памяти на логическом уровне. Последние 224 слова образуют об¬ 
ласть каждой страницы, используемую для хранения данных. 

Указанные 224 слова до¬ 



ступной пользователю памя¬ 
ти каждой страницы под¬ 
разделяются на 28 распре¬ 
деляемых областей памяти, 
состоящих из восьми слов и 
называемых группами-, при¬ 
чем каждая группа имеет 
свое слово связи группы. 
Если теперь вновь обратить¬ 
ся к некоторым примерам 
гл. 9, становится ясно, что, 
хотя такая строка данных, 
как таблица имен или стро¬ 
ка объектного кода, и не 
обязательно размещается в 
смежных областях вирту¬ 
альной памяти, каждый сег¬ 
мент строки размером в 
восемь слов занимает смеж¬ 
ные ячейки памяти. 


Рис. 10.1. Распределение страниц Чтобы понять возникно- 

виртуальной памяти. вение принципов логической 


памяти, рассмотрим описа¬ 
ние формата слова связи 
группы (табл. 10.3) . Каждое слово связи группы содержит ссыл¬ 
ки в прямом и обратном направлении; этими ссылками являются 
виртуальные адреса следующей и предшествующей групп в дан¬ 
ной строке логической памяти. Говоря иначе, строки логической 


памяти представляются в виде цепочек слов связи групп и групп 
слов с данными, относящимися к этим словам связи. Заметим, 
что адреса, указанные в табл. 10.3, являются 24-битовыми ад¬ 
ресами виртуальной памяти. Отсюда следует, что слова связи 
групп могут ссылаться на группы, находящиеся на других стра¬ 
ницах памяти, т. е. строка логической памяти может быть раз¬ 
мещена на нескольких страницах. 

Чтобы понять, каким образом происходит распределение па¬ 
мяти, предположим, что некоторый процессор, выполняющий 
обработку для пользователя А, посылает контроллеру памяти 
запрос на выделение в памяти группы слов (AG). Вначале 
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контроллер осуществляет поиск страницы виртуальной памяти,, 
предназначенной данному пользователю, в которой имелось бы 
свободное пространство памяти. (Здесь мы опускаем процедуру 
поиска контроллером памяти такой страницы. Заметим также, 
что если такая страница не может быть обнаружена, то конт¬ 
роллер найдет неиспользуемую страницу и назначит ее пользо¬ 
вателю А.) 

Положим, что страни- - 
ца найдена, в ней уже 
распределены группы І, 

3 и 5, а остальные груп¬ 
пы свободны. Информа¬ 
ция об этом регистриру¬ 
ется следующим образом. 

Заголовок страницы име¬ 
ет два 5-битовых поля, 
называемых началом 
списка свободных групп 
(AGLS — available group 
list start) и счетчиком 
распределенных групп 
(IGAC — initial group 
assignment counter). 

В данном случае содер¬ 
жимое поля AGLS рав¬ 
но 2, содержимое поля 
IGAC — 6; в слове связи 
группы 2 находится виртуальный адрес группы 4, а бит 33 сло¬ 
ва связи группы 4 равен 0. Другими словами, свободные группы 
объединены в список, а в поле IGAC находится номер первой 
группы из этого списка. 

Однако если последние п групп страницы свободны, то они 
не связываются между собой с целью образования списка (сле¬ 
довательно, и не строится список в описанной выше форме); 
вместо этого в поле IGAC помещается номер первой из этих, 
групп. 

При выполнении операции выделения группы слов памяти 
(операции AG) контроллер памяти прежде всего выясняет, не- 
содержит ли поле IGAC число 29. Затем он вычисляет вирту¬ 
альный адрес первого слова группы 6, добавляет 1 к содержи¬ 
мому поля IGAC и производит возврат этого адреса процессо¬ 
ру, пославшему запрос. Если бы содержимое поля IGAC рав¬ 
нялось 29, то контроллер взял бы группу из списка свободных, 
групп. 

Если следующим запросом является запись данных в память- 
и получение адреса следующего слова (операция SA), tq koht- 
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роллер памяти должен возвратить адрес следующего слова в 
данной строке. Если заданный в запросе адрес не относится к 
последнему слову группы, то контроллер просто увеличивает 
этот адрес на 1 и производит его возврат. После семикратного 
выполнения операции SA для данной строки контроллер памя¬ 
ти обнаруживает, что данные записываются в последнее слово 
группы. В этот момент выполняется рассмотренный ранее про¬ 
цесс поиска свободной группы. Полагая, что в результате поис¬ 
ка найдена свободной группа 7, контроллер помещает адрес 
группы 7 в Поле слова связи группы 6, предназначенное для 
ссылки на следующую группу строки, а адрес группы 6 — в поле 
слова связи группы 7, предназначенное для ссылки на преды¬ 
дущую группу строки, и возвращает адрес первого слова груп¬ 
пы 7. Обычно при этом контроллер памяти быстро обслуживает 
семь из восьми запросов, в то время как выполнение восьмого 
запроса требует существенного дополнительного времени. 

Работа контроллера памяти при обслуживании запросов дру¬ 
гого типа достаточно понятна. Например, при выполнении опе¬ 
рации FF (выборка данных и осуществление возврата адреса 
следующего слова) контроллер передает указанный в запросе 
адрес, увеличенный на 1, если выбираемое слово не является 
последним в группе. Если же это слово последнее в группе, 
то контроллер должен определить адрес следующего слова 
строки путем обращения к слову связи данной группы, поиска 
(с помощью ссылки вперед по списку) слова связи следующей 
группы и передачи запрашивающему процессору адреса пер¬ 
вого слова этой группы. 

ВОССТАНОВЛЕНИЕ ГРУППЫ СЛОВ 

Если в дальнейшем процессору строка не нужна, он посылает 
запрос контроллеру памяти на ее освобождение. Процесс осво¬ 
бождения памяти, занимаемой строкой, представляет собой опе¬ 
рацию, требующую значительного времени. Конечным резуль¬ 
татом этой операции является добавление групп слов, в кото¬ 
рых находилась строка, в список свободных групп; но выпол¬ 
нить это не так просто, как кажется на первый взгляд. Поскольку 
строка может быть размещена по нескольким страницам вир¬ 
туальной памяти (а каждая страница имеет свой собственный 
список свободных групп слов), строка должна быть разделена 
на части, относящиеся к отдельным страницам, и группы, в ко¬ 
торых размещаются эти части строки, должны быть включены 
в списки свободных групп каждой страницы. Помимо того что 
на все это уходит значительное количество машинного време¬ 
ни, может потребоваться еще дополнительное время при обна¬ 
ружении отсутствия требуемой страницы, так как некоторые 
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страницы виртуальной памяти могут не находиться в данный 
момент в основной памяти. 

Дополнительные затруднения возникают по той причине, что 
строка может ссылаться на другие строки, а удаление строки 
предполагает необходимость изъятия всех строк, связанных с 
данной строкой. Примером такой ситуации является использо¬ 
вание структур языка SPL. Предположим, что А — структура,, 
а строка, представляющая ее в памяти, должна быть исключе¬ 
на. Если некоторые элементы структуры А сами являются 
структурами, то строка, представляющая А, содержит адреса- 
других строк, последние в свою очередь могут ссылаться на 
некоторые строки. Например, если элемент А[1]—структура,, 
то первое слово первой группы слов строки, представляющей А, 
содержит не значение данных, а адрес другой строки. 

Если бы указанные выше действия выполнялись контролле¬ 
ром памяти всякий раз при получении им запроса на исключе¬ 
ние строки, то контроллер был бы занят чрезмерно длительный 
интервал времени, буквально приостанавливая работу всей си¬ 
стемы. Решением данной проблемы является использование в 
архитектуре системы отдельного процессора — регенератора па¬ 
мяти. Контроллер памяти обрабатывает запрос на исключение 
строки быстро — благодаря тому, что ему достаточно только 
добавить эту строку к одному из списков «информационного 
мусора», т. е. списков использованных, подлежащих удалению 
строк. Всю же работу по восстановлению памяти выполняет 
регенератор памяти. 

Регенератор памяти имеет самый низкий приоритет досту¬ 
па к ней; он может посылать запросы контроллеру памяти толь¬ 
ко тогда, когда последний свободен, другие процессоры не по¬ 
сылают свои запросы контроллеру памяти, и обмен сигналами' 
управления между процессорами не происходит. 

Регенератор памяти непрерывно просматривает списки «ин¬ 
формационного мусора». При обнаружении содержимого в по¬ 
добном списке регенератор памяти удаляет первую строку и 
просматривает все слова связи групп. Регенератор памяти вы¬ 
полняет это, посылая стандартные запросы контроллеру памяти. 
Регенератор памяти добавляет каждую группу строки к списку 
свободных групп соответствующей страницы, посылая запросы 
на освобождение групп (операция RG) контроллеру памяти. 
Таким образом, контроллер памяти играет подчиненную роль в 
процессе восстановления памяти, действуя как «подпрограмма» 
этого процессора. 

Если строка содержит адреса других строк, регенератор па¬ 
мяти просматривает каждое слово каждой группы строки, осу¬ 
ществляя поиск не значений данных, а их адресов. При обна¬ 
ружении подобного адреса адресуемая им строка добавляет- 

ів* 
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•ся в список строк, подлежащих удалению. Таким образом, па¬ 
мять, занимаемая этими строками, будет освобождаться во вре¬ 
мя последующих просмотров данного списка. (Адреса, подобно 
•строкам данных, сами определяют свой тип; адресам предше¬ 
ствует байт, содержащий код ЕС, указывающий ссылку на 
•структуру, являющуюся элементом данной структуры.) 


РАСПРЕДЕЛЕНИЕ СТРАНИЦ 

виртуальной памяти 

До сих пор при обсуждении процесса распределения памяти не 
рассматривался вопрос о том, как контроллер памяти находит 
•свободную страницу. В данном разделе дается ответ на этот 
вопрос, а также описывается управление страницами виртуаль¬ 
ной памяти. Управление страницами подобно управлению груп¬ 
пами слов и основано на использовании списков свободных 
страниц и списков страниц, содержащих «информационный му¬ 
сор». Одна из системных таблиц в основной памяти содержит 
заголовок (начальный адрес) списка свободных страниц, в ко¬ 
тором находятся все страницы, не выделенные в данный мо¬ 
мент пользователю. В заголовке каждой страницы имеется 
16-битовое поле, используемое для соединения страниц в еди¬ 
ный список. Если страница является свободной, то содержи¬ 
мое поля указывает на связь этой страницы со списком свобод¬ 
ных страниц. 

Как уже упоминалось, в основной памяти для каждого поль¬ 
зователя имеется управляющая таблица. Все страницы, выде¬ 
ленные в данный момент для обслуживания пользователя, свя¬ 
заны между собой, однако для каждого пользователя предна¬ 
значен не один, а три списка страниц (TPL1, TPL2 и TPL3). 
Заголовки этих трех списков находятся в каждой управляющей 
таблице пользователя. 

Целью использования трех списков страниц является мини¬ 
мизация числа страниц, находящихся в основной памяти, пу¬ 
тем выделения одной и той же страницы (страниц) для совме¬ 
стно используемых данных, программ и таблиц. В соответствии 
с принятыми для системы соглашениями список TPL1 включа¬ 
ет страницы, в которых находится временная рабочая область 
пользователя (содержащая, например, текст исходной програм¬ 
мы); в список TPL2 входят страницы с таблицами имен про¬ 
грамм, стеками, используемыми центральным процессором, и об¬ 
ластями для размещения значений переменных программ во 
время их выполнения; список TPL3 содержит страницы, содер¬ 
жащие объектный код программ пользователя. 

Эти три списка показаны на рис. 10.3, для упрощения кото¬ 
рого изображены только девять страниц и одна управляющая 
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таблица пользователя. Рисунок не столь сложен, если рассмат¬ 
ривать каждый список отдельно. Страницы 2, 4 и 9 в данный 
момент не распределены и включены в список свободных стра¬ 
ниц. Страница 3 находится в списке TPL1 пользователя А, и, 
поскольку часть ее памяти свободна, она также входит в спи¬ 
сок свободных областей памяти страниц, включенных в список 



Рис. 10.3. Пример организации списков страниц виртуальной 
памяти в системе SYMBOL. 

TPL1. Страницы 7, 6 и 8 находятся в списке TPL2; в страницах 
7 и 8 имеется свободная память, и они включены в список сво¬ 
бодных областей памяти, связанный со списком TPL2. Страни¬ 
цы 1 и 5 образуют список TPL3, причем страница 5 включена 
в соответствующий список свободных областей памяти. 

Как указывалось ранее, при обращении к памяти процессор 
помещает код функции обращения на шесть линий МС основ¬ 
ной шины: на четыре линии код, показывающий, какая из 14 
возможных операций обращения к памяти подлежит выполне¬ 
нию; на две другие линии код, определяющий, к какому из трех 
списков страниц памяти пользователя относится данный запрос 
(этот код используется только при выполнении операций, свя¬ 
занных с распределением памяти). 

Предположим, что центральный процессор посылает контрол- 
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леру памяти запрос на выполнение операции AG (выделить 
группу слов памяти) и указывает, что этот запрос должен от¬ 
носиться к списку TPL2. Контроллер просматривает список сво¬ 
бодных областей памяти на страницах, входящих в список 
TPL2. Если список свободных областей памяти не является пу¬ 
стым, то распределяется группа слов из страницы, находящей¬ 
ся первой в данном списке. Если же этот список пустой 1 ), конт¬ 
роллер памяти исключает страницу из списка свободных стра¬ 
ниц, добавляет ее в список TPL2 и список свободных областей 
памяти страниц списка TPL2, помещает 1 в поле IGAC (initial 
group assignment counter — счетчик количества первоначально 
распределенных групп слов страницы) и выделяет для запраши¬ 
вающего процессора группу слов из этой страницы. 

ВОССТАНОВЛЕНИЕ СТРАНИЦ 

Освобождение (восстановление или регенерация) страниц вы- 
полняется регенератором памяти способом, подобным освобож¬ 
дению групп слов. Предположим, пользователь только что за¬ 
кончил компилирование и выполнение программы и намерева¬ 
ется осуществить пуск другой программы. Принимая команду 
RUN (ПУСК), супервизор системы помещает списки TPL2 и 
TPL3 пользователя в очередь запросов к регенератору памяти и 
заполняет нулями заголовки списков TPL2 и TPL3. Регенера¬ 
тор памяти добавляет каждую страницу в список свободных 
страниц, посылая контроллеру памяти запросы типа DL (см. 
табл. 10.2). 

Освобождая страницу, регенератор заполняет ее нулями,, 
так что распределение и освобождение групп слов страницы не 
приводит к ее некорректному использованию. Следовательно, 
нет необходимости в исключении каждой строки страницы спис¬ 
ка страниц, подлежащих освобождению. Таким образом, коли¬ 
чество запросов на исключение строк, обрабатываемых конт¬ 
роллером памяти, меньше количества запросов на распределе¬ 
ние групп слов. 

СУПЕРВИЗОР 

Супервизор системы — это процессор, выполняющий функции, 
обычно реализуемые операционной системой. Другие процессо¬ 
ры подчинены супервизору, который указывает им, что делать. 
Супервизор является в то же время пассивным процессором в 
том смысле, что его работа инициируется сигналами прерыва¬ 
ния, посылаемыми другими процессорами. Супервизор обслу- 


’> То есть на страницах, входящих в список TPL2, нет свободных обла¬ 
стей памяти. — Прим, перев. 
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живает эти прерывания, либо обращаясь к другим процессорам, 
либо сам выполняя требуемую обработку. 

Основные функции супервизора системы заключаются в управ¬ 
лении другими процессорами путем обслуживания их рабочих 
очередей, планирования операций страничного обмена при об¬ 
наружении отсутствия в основной памяти требуемой страницы 
виртуальной памяти и управления системными управляющими 
таблицами и управляющими таблицами пользователей. Про¬ 
цессом страничного обмена управляет не контроллер памяти, 
а супервизор, потому что последний имеет более «широкое 
представление» о функционировании системы и может прини¬ 
мать более эффективные решения, связанные с процессом за¬ 
мещения страниц. 

ПРОЦЕСС ОБМЕНА СТРАНИЦАМИ 

Во время цикла выдачи ответа на обращение к памяти супер¬ 
визор системы постоянно контролирует сигналы на линиях МС. 
Если на этих линиях появляется код 000001 (отсутствие требуе¬ 
мой страницы виртуальной памяти), то супервизор регистриру¬ 
ет адрес памяти, передаваемый по шине в данный момент; та¬ 
ким образом он узнает, какая страница виртуальной памяти 
должна быть загружена в основную память. Если супервизор 
системы обнаруживает на этих линиях код завершения 
100011, указывающий на успешное выполнение запроса на об¬ 
ращение к памяти и требование к контроллеру памяти исклю¬ 
чить страницу из списка свободных страниц, супервизор увели¬ 
чивает содержимое счетчика числа страниц, предоставляемых в 
распоряжение данному пользователю. Показания этого счет¬ 
чика используются для завершения работы тех пользователей, 
запросы которых на выделение памяти превышают некоторое 
пороговое значение (например, при зацикливании программы, 
проявляющемся в запросе на выделение чрезмерно большого 
объема памяти). 

Процесс страничного обмена начинается, когда процессор 
посылает супервизору системы управляющий сигнал, указыва¬ 
ющий на отсутствие страницы в основной памяти. Супервизор 
инициирует выполнение процедуры замещения страниц (реали¬ 
зуемой аппаратными средствами, поскольку супервизор систе¬ 
мы не имеет программного обеспечения) и помещает запросы 
на страничный обмен в очередь к контроллеру памяти на маг¬ 
нитных дисках. Это могут быть запросы на передачу страницы 
из основной памяти в память на магнитных дисках или из па¬ 
мяти на магнитных дисках в основную память. Затем суперви¬ 
зор просматривает очередь процессора, не обнаружившего в ос¬ 
новной памяти нужную страницу, отыскивает в очереди запрос 
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пользователя и помечает этот запрос как находящийся в ожи¬ 
дании нужной страницы, оставляя его в текущей позиции оче¬ 
реди запросов к данному процессору. Последнему же назнача¬ 
ется выполнение другого запроса очереди. 

Все дорожки магнитных дисков, используемых в качестве 
страничной памяти, разделены на четыре сектора. Страница 
размещается в пределах одного сектора. Каждой странице вир¬ 
туальной памяти зарезервирована определенная позиция на 
диске. При вращении диска его контроллер получает информа¬ 
цию о том, какой сектор должен быть следующим под головкой 
чтения/записи. Контроллер в свою очередь передает эту инфор¬ 
мацию супервизору системы. Последний использует ее для ми¬ 
нимизации потерь времени, связанных с задержкой вращения 
накопителя, а именно выдает команду контроллеру памяти на 
обращение к соответствующему элементу его входной памяти. 

Существует еще один список страниц, не показанный на 
рис. 10.3. Это список страниц виртуальной памяти, находящихся! 
в данный момент в основной памяти. Одно из полей заголовка 
каждой страницы используется в качестве поля связи этого 
списка. По завершении операции страничного обмена суперви¬ 
зор включает новую страницу в конец данного списка. (Вытес¬ 
ненная из основной памяти страница исключается из списка 
при выдаче запросов на страничный обмен.) Супервизор завер¬ 
шает процесс удалением отметки об ожидании страницы с за¬ 
проса пользователя, находящегося в очереди на обслуживание 
процессором, обнаружившим отсутствие в основной памяти не¬ 
обходимой страницы виртуальной памяти. 

ЗАМЕЩЕНИЕ СТРАНИЦ 

Алгоритм замещения страниц, реализуемый супервизором си¬ 
стемы, представляется достаточно интересным, поскольку, во- 
первых, он построен по принципу FIFO (first in, first out), 
в соответствии с которым предпочтение отдается обслуживанию 
программы, находящейся в начале очереди центрального про¬ 
цессора. Во-вторых, алгоритм использует глобальную информа¬ 
цию о состоянии системы с целью определения страницы, исклю¬ 
чение которой из основной памяти в данный момент является: 
наиболее рациональным. 

Для каждой страницы, находящейся в основной памяти, су¬ 
первизор вычисляет индекс резидентности страницы, являющий¬ 
ся мерой целесообразности сохранения страницы в основной па¬ 
мяти. Индекс назначается в соответствии с положениями, при¬ 
веденными в табл. 10.4. 

Индекс 0 присваивается в основном страницам, вероятность 
цстодьзования которых в ближайшем будущем мала. Такими 




ВНУТРЕННЯЯ СТРУКТУРА ПРОЦЕССОРОВ СИСТЕМЫ SYMBOL 249 


Таблица 10.4. Присвоение страницам значений индекса резидентное™ 


Индекс ре¬ 
зидентности 
страниц 

Название и местоположение страниц 

3 

Страницы, принадлежащие пользователю, запрос на обслу¬ 
живание которого находится в начале очереди центрального 
процессора 

2 

Страницы, принадлежащие другим пользователям, запросы на 
обслуживание которых находятся в очереди центрального 
процессора 

2 

Страницы, содержащие таблицы имен (т. е. страницы, вклю¬ 
ченные в списки TPL2), принадлежащие пользователям, за¬ 
просы на обслуживание которых находятся в очереди тран¬ 
слятора 

1 

Страницы, принадлежащие пользователям, запросы на обслу¬ 
живание которых находятся в очереди процессора интерфей¬ 
са ввода-вывода 

1 

Страницы, не содержащие таблицы имен, принадлежащие 
пользователям, запросы на обслуживание которых находят¬ 
ся в очереди транслятора 

0 

Все другие страницы 


страницами являются свободные страницы, страницы, принад¬ 
лежащие пользователям, в работе которых наступила пауза 
или программы которых только что завершили выполнение, 
а также страницы пользователей, время обслуживания которых 
процессором только что превысило допустимый временной ин¬ 
тервал. 

В процессе замещения страниц супервизор также вычисляет 
приоритет загрузки страницы виртуальной памяти пользовате¬ 
ля при обнаружении отсутствия требуемой страницы в основ¬ 
ной памяти. Если запрос на обработку, относящийся к пользо¬ 
вателю, является первым в очереди центрального процессора, 
то загрузке страницы присваивается приоритет 3. Если запрос 
пользователя на обслуживание является первым в очереди 
транслятора или процессора интерфейса ввода-вывода, то при¬ 
оритету загрузки страницы присваивается большее из следую¬ 
щих двух значений: 2 или приоритет, присвоенный пользовате¬ 
лю (который может принимать значение 0, 1, 2 или 3). Для лю¬ 
бых других запросов приоритет загрузки страницы присваива¬ 
ется согласно приоритету пользователя. 

Для нахождения страницы, подлежащей удалению из основ¬ 
ной памяти, супервизор просматривает очередь страниц, нахо¬ 
дящихся в основной памяти, от начала до конца (как говорят, 
сверху вниз). Выбирается та страница, индекс резидентности 
которой меньше приоритета загрузки. Если такую страницу 
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найти не удается, то удаляется первая страница списка, индекс 
резидентности которой равен приоритету загрузки страницы 
пользователя, отсутствующей в основной памяти. Если и такой 
страницы в списке нет, то супервизор отказывается от выпол¬ 
нения запроса на страничный обмен и не помечает находящий¬ 
ся в очереди запрос пользователя как ожидающий вызова стра¬ 
ницы. В конечном счете процессор, ранее обнаруживший от¬ 
сутствие нужной страницы в основной памяти, установит еще 
раз факт отсутствия той же самой страницы в этой памяти. Од¬ 
нако можно надеяться, что к тому времени состояние системы 
изменится и требуемую страницу виртуальной памяти можно 
будет загрузить в основную память. 

Итак, алгоритм замещения страниц не произвольно выби¬ 
рает страницу, подлежащую исключению из основной памяти, 
а принимает решение, основанное на следующей информации: 
приоритете задания пользователя, при выполнении которого 
возникла потребность в вызове страницы виртуальной памяти, 
а также содержимом каждой страницы и приоритете заданий 
пользователей, каждому из которых принадлежит страница вир¬ 
туальной памяти, загруженная в основную память. Пользова¬ 
тель, запрос которого является первым в очереди центрально¬ 
го процессора, обслуживается системой наилучшим образом. 
Он может «отнимать» страницу у других пользователей (в том 
числе и свои собственные страницы, использованные во время 
предыдущих обращений к памяти), однако никакой другой 
пользователь не может «отнять» у него страницы, расположен¬ 
ные в основной памяти и принадлежащие ему. 


УПРАВЛЕНИЕ ОЧЕРЕДЬЮ ПРОЦЕССОРА 

Одной из функций супервизора системы является добавление 
запросов в очередь каждого процессора, их изъятие оттуда и 
передача сообщения каждому процессору о том, какой запрос 
из очереди подлежит обработке. Этот алгоритм реализуется 
аппаратными средствами, однако на него оказывают влияние 
параметры, хранимые в основной памяти. Указатели начала и 
конца очереди содержатся в области системных таблиц в ос¬ 
новной памяти. 

Когда процессор может выполнять новую работу, суперви¬ 
зор указывает ему элемент очереди (запрос), подлежащий об¬ 
работке, путем просмотра очереди процессора с начала до кон¬ 
ца. При этом выбирается запрос, находящийся в очереди пер¬ 
вым среди запросов, не ожидающих вызова в основную память 
страницы виртуальной памяти. Когда запрос помещается в оче¬ 
редь, то для него устанавливается интервал времени нахожде¬ 
ния в очереди в состоянии выполнения, определяемый значени- 
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ем соответствующего системного параметра. Супервизор перио¬ 
дически уменьшает величину этого интервала для всех элемен¬ 
тов очереди, обслуживаемых процессором. Если для какого-ни¬ 
будь элемента очереди указанная величина становится равной О, 
то элемент перемещается в конец очереди и интервалу времени 
его выполнения повторно присваивается начальное значение. 
Таким образом, запрос пользователя обслуживается процессо¬ 
ром до тех пор, пока не истечет допустимый интервал времени 
нахождения его в очереди в состоянии выполнения, после чего 
вероятность его обслуживания резко уменьшается. Кроме то¬ 
го, новые запросы всегда помещаются в начало очереди для 
того, чтобы быть уверенными, что они получат (по крайней 
мере первоначально) приоритет в обслуживании. 

Другой системный параметр управляет глубиной просмотра 
супервизором очереди процессора. Если размер очереди пре¬ 
вышает значение данного параметра, то запросы пользователей, 
исчерпавшие предоставленный им промежуток времени, пере¬ 
мещаются в конец очереди и временно исключаются из цикла 
мультипрограммной работы процессора. 

Интервал времени нахождения запроса в очереди в состоя¬ 
нии выполнения предназначен для управления задачами, загру¬ 
жающими работой процессор. Однако это не препятствует задаче 
страничного обмена монополизировать основную память и про¬ 
цессор, поскольку для подобной задачи характерна тенденция 
располагаться в начале очереди на чрезмерно длительное вре¬ 
мя. Поскольку подобная ситуация наиболее часто бывает у 
центрального процессора, то запрос, находящийся в начале 
очереди центрального процессора, контролируется системным 
параметром, определяющим максимально допустимое время 
нахождения запроса в начале очереди. Если период пребывания 
запроса в начале очереди превышает значение данного пара¬ 
метра, то запрос перемещается в конец очереди. 

ЦЕНТРАЛЬНЫЙ ПРОЦЕССОР 

Центральный процессор выполняет объектные коды программ 
на языке SPL. В процессе своей работы он обращается в па¬ 
мяти к адресатам четырех типов: объектной программе, таб¬ 
лице имен, стеку и памяти, используемой для хранения данных. 
Стек центрального процессора — это список, размещенный в 
виртуальной памяти; обращение к стеку центральный процес¬ 
сор осуществляет с помощью контроллера памяти. 

Часть управляющей таблицы каждого пользователя в ниж¬ 
ней области основной памяти используется центральным про¬ 
цессором для хранения информации о состоянии программы 
пользователя. Наряду с другой информацией центральный про- 
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цессор хранит в этих управляющих таблицах адрес объектной 
программы, адрес используемой в данный момент таблицы 
имен, адрес текущего стека, адрес выполняемой команды и те¬ 
кущее значение параметра ЫМД 1 ). 

ВНУТРЕННИЕ ФОРМЫ ПРЕДСТАВЛЕНИЯ ДАННЫХ 

Согласно гл. 9, центральный процессор обрабатывает данные, 
используя их внутреннее представление, более эффективное 
для обработки. При обмене данными с другими процессорами 
(например, с транслятором или процессором интерфейса ввода- 
вывода) центральный процессор выполняет преобразование 
формы представления данных из внешней во внутреннюю и об¬ 
ратно. Внешним представлением скаляра, как показано в 
гл. 9, является строка. Если эти данные не являются числом, 
то их внутреннее представление подобно внешнему. Если ска¬ 
ляр— число, то он записывается во внутренней форме пред¬ 
ставления данных, называемой числовой формой. 

Числовая форма — это упакованная десятичная запись (две 
цифры в байте) числа, представляемого в виде значений ман¬ 
тиссы и порядка, т. е. числа с плавающей точкой. Числа запи¬ 
сываются в поле, длина которого равна целому числу слов, 
причем старший бит в последнем байте последнего слова чис¬ 
лового поля устанавливается равным 1. Первый байт представ¬ 
ляет собой указатель типа данных — тег, определяющий дан¬ 
ные как числовые и указывающий знаки порядка и мантиссы. 
Код F0 в этом байте означает положительные значения ман¬ 
тиссы и порядка, F1 —отрицательное значение мантиссы и по¬ 
ложительное значение порядка, F2 — положительное значение 
мантиссы и отрицательное значение порядка и F3 — отрицатель¬ 
ные значения мантиссы и порядка. 

Второй байт определяет величину порядка (00—99). Первые 
четыре бита после последней цифры мантиссы должны соответ¬ 
ствовать шестнадцатеричным цифрам F или Е: F — обозначает 
точное значение числа, Е — приближенное. Например, число 
1283 представляется в следующем виде: 

F0 04 12 83 FX XX FX 
а число—1234567.891234567ЕМ в виде 

F1 07 12 34 56 78 91 00 

00 00 23 45 67 EX XX ЕХ 

Как показано выше, для представления мантиссы в каждом 
слове используются только байты с 3-го по 7-й. 


*> Этот параметр определяет точность (число разрядов) представления 
числовых значений операндов. — Прим, перев. 
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Внутреннее представление структур называется нормаль¬ 
ным. В такой форме структуры записываются в память в виде 
одного или нескольких векторов, причем в памяти каждый век¬ 
тор представлен списком (строкой). Компоненты вектора раз¬ 
мещаются в списке последовательно; список завершается сло¬ 
вом, начинающимся с управляющего знака «конец вектора> 
(код F7). Однако если компонента вектора — структура, то она 
представляется в списке в виде указателя подгруппы структу¬ 
ры. Указатель подгруппы имеет следующий формат: 

ЕС АААААА SS ВВВВВВ 

где АААААА — адрес вектора, представляющего подгруппу 
структуры; SS — значение индекса компоненты вектора, послед¬ 
ней из тех компонент, к которым производилось обращение, 
ВВВВВВ — адрес этой компоненты. (Как показано в табл. 9.3, 


Представление 



Рис. 10.4. Внутреннее представление структуры. 


эти две последние величины — SS и ВВВВВВ — содержатся 
также в управляющих словах идентификаторов структур.) Ве¬ 
личины SS и ВВВВВВ используются для быстрого выполнения 
операций индексирования. Утверждение о достижении повы¬ 
шенного быстродействия этих операций основано на предполо- 
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жении, что если последнее обращение производилось к і-й ком¬ 
поненте структуры, то следующее обращение будет осуществ¬ 
ляться к этому же элементу или к одному из элементов, рас¬ 
положенному в списке после і-й компоненты (например, к (і+ 
+ 1)-й компоненте). При определении индекса компоненты 
центральный процессор сравнивает значение индекса с величи¬ 
ной SS. Если индекс больше этой величины или равен ей, то 
поиск требуемой компоненты начинается не с адреса АААААА, 
а с адреса ВВВВВВ. 

Рис. 10.4 иллюстрирует внутреннее представление структу¬ 
ры, имеющей, с точки зрения пользователя, форму «неправиль¬ 
ного» массива (таблицы с недостающими элементами). Первый 
вектор структуры включает три компоненты, две из которых яв¬ 
ляются указателями подгрупп структуры. Все скаляры пред¬ 
ставлены в своей внутренней числовой форме. Если предполо¬ 
жить, что последним обращением к структуре (назовем ее S) 
•было S|[2, 1], а обращением, ему предшествующим, — S [ 1,3], 
то рисунок наглядно демонстрирует использование полей «бы¬ 
строго поиска», содержащих величины SS и ВВВВВВ. 


ЧЕТЫРЕ ПОДПРОЦЕССОРА 

Центральный процессор состоит из четырех подпроцессоров, 
каждый из которых имеет собственный набор регистров и ариф¬ 
метических устройств. Подпроцессоры подключены к 8-разряд- 
ной управляющей шине для передачи между ними управляю¬ 
щих сигналов, а также к основной шине для обмена данными 
•между ними. Подпроцессоры используют основную шину, ког¬ 
да она не занята другими процессорами. 

Основным подпроцессором в центральном процессоре явля¬ 
ется устройство управления последовательностью выполнения 
машинных команд. Это устройство выбирает следующую коман¬ 
ду, подлежащую выполнению, и обрабатывает команды с лите¬ 
ральными данными, команды перехода и вызова процедур. Для 
обработки команд другого типа устройство управления последо¬ 
вательностью обращается к остальным подпроцессорам. 

Вторым подпроцессором служит арифметический процессор, 
обрабатывающий все арифметические команды и команды срав¬ 
нения числовых данных. Функциями этого процессора являются 
также и вычисления с управляемой точностью, для чего ис¬ 
пользуется регистр, содержащий значение параметра LIMIT. 

Третий подпроцессор — это процессор преобразования фор¬ 
матов, обрабатывающий все команды, которые оперируют ска¬ 
лярами и логическими величинами, и осуществляющий автома¬ 
тическое преобразование данных из числового представления в 
строку символов и обратно. 
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Четвертым подпроцессором является процессор адресации 
данных. Он управляет командами выполнения операций при¬ 
сваивания и обращается к таблице имен по запросам других 
процессоров, однако его основное назначение состоит в мани¬ 
пулировании структурами. Он ответствен за преобразование 
формы представления структуры линейной в нормальную и об¬ 
ратное преобразование. Кроме того, именно этот подпроцессор* 
обрабатывает сложные ситуации, такие, как присвоение эле¬ 
менту структуры «значения» другой структуры или скаляра,, 
размер которого превышает размер данного элемента струк¬ 
туры. 

Основная часть процессора адресации данных выполняет опе¬ 
рации индексирования элементов структуры. Для повышения 
эффективности выполнения этих операций (исключения обяза¬ 
тельного просмотра всех компонент вектора, начиная с первой 
компоненты) учитывается информация, содержащаяся в полях 
индексов последних использованных компонент вектора. Од¬ 
нако операции с индексами занимают много времени, посколь¬ 
ку элементы могут иметь различную длину, а их слова могут 
быть размещены в разных страницах виртуальной памяти. Что¬ 
бы избежать просмотра данным процессором каждого слова 
строки в поисках требуемого слова, используется 8-битовое по¬ 
ле «быстрого поиска» слова связи группы слов страницы (см. 
табл. 10.3). Эти 8 бит соответствуют восьми словам группы. 
Единичное значение бита «быстрого поиска» указывает на то, 
что соответствующее слово является первым словом элемента 
вектора (компоненты). Следовательно, если процессору адре¬ 
сации данных нужно обратиться к 14-й компоненте, ему пона¬ 
добится просматривать слова связи групп только до тех пор, 
пока не встретится 14-й единичный бит «быстрого поиска»; в 
просмотре каждого слова соответствующих групп нет необходи¬ 
мости. 


ТРАНСЛЯТОР 

Транслятор — это процессор, транслирующий (компилирую¬ 
щий) исходную программу, составленную на языке SPL, в со¬ 
ответствующие ей объектную программу и одну или несколько' 
таблиц имен. Как упоминалось в гл. 8, этот процесс выполняет¬ 
ся не программными, а аппаратными средствами (посредством 
последовательностных логических схем). 

Транслятор функционально разделен на две секции: генери¬ 
рования объектного кода и формирования таблицы имен. Пер¬ 
вая секция просматривает исходную программу и создает со¬ 
ответствующую объектную программу. Когда в процессе этого 
просмотра встречается буква, не принадлежащая литеральным 
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данным (она может быть первой буквой идентификатора или 
зарезервированного слова), управление передается второй сек¬ 
ции. Секция формирования таблицы имен продолжает просмотр 
символов этого слова (имени) языка SPL, пока в нем не встре¬ 
тится ограничитель. После этого она просматривает таблицу за¬ 
резервированных слов, хранимую в основной памяти. Если об¬ 
наруженное в тексте программы имя представляет собой заре¬ 
зервированное слово, секция формирования таблицы имен гене¬ 
рирует соответствующий код операции. 

Если обнаруженное имя не является зарезервированным сло¬ 
вом, то анализируется содержимое текущей таблицы имен. Ес¬ 
ли в этой таблице имеется данное имя, то в секцию генерирова¬ 
ния объектного кода передается адрес соответствующего управ¬ 
ляющего слова идентификатора. В противном случае в табли¬ 
цу имен добавляется это имя и формируется новое управляю¬ 
щее слово идентификатора, адрес которого передается в секцию 
генерирования объектного кода. 

После того как таблицы имен и объектные коды всех бло¬ 
ков исходной программы сформированы, выполняется процесс 
разрешения внешних (глобальных) ссылок. Секция формирова¬ 
ния таблиц имен просматривает таблицы имен, осуществляя 
поиск глобальных идентификаторов. При обнаружении такого 
■идентификатора осуществляется обращение к таблице имен 
внешнего блока посредством указателя этого блока, располо¬ 
женного в управляющем слове данного блока, после чего гло¬ 
бальные идентификаторы связываются с соответствующими 
идентификаторами внешних блоков программы. 

Второй процесс установления связей относится к обработ¬ 
ке неразрешенных ссылок на процедуры. Если обнаруживается 
имя вызываемой процедуры, отсутствующей в тексте исходной 
программы, то осуществляется поиск этой процедуры в систем¬ 
ных библиотеках или личных библиотеках пользователей. По¬ 
скольку программы хранятся в библиотеках в исходном виде, 
процесс трансляции должен быть продолжен; при этом созда¬ 
ются новые таблицы имен, а к ранее сформированному объект¬ 
ному коду программы дописывается дополнительный объект¬ 
ный код. 

ОСТАЛЬНЫЕ ПРОЦЕССОРЫ 

Из общего набора процессоров системы SYMBOL не были рас¬ 
смотрены следующие: процессор интерфейса ввода-вывода, пе¬ 
редающий данные между виртуальной памятью и буферами 
ввода-вывода, выполняющий запрашиваемые с терминала опе- 
ірации редактирования текста и управляющий операциями вво¬ 
да-вывода, инициируемыми объектными программами; контрол- 
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лер каналов ввода-вывода, организующий передачу данных 
между низкоскоростными устройствами ввода-вывода (напри¬ 
мер, терминалами) и буферами ввода-вывода; контроллер па¬ 
мяти на магнитных дисках, управляющий передачей данных 
между основной памятью и устройствами внешней памяти; лро- 
цессор обработки машинных сбоев. 

Назначение и принципы функционирования этих процессоров 
достаточно просты, поэтому их описание может быть опущено. 

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ 

Как отмечалось выше, система SYMBOL может функциониро¬ 
вать без программного обеспечения. Однако опыт работы с си¬ 
стемой показал целесообразность разработки средств програм¬ 
много обеспечения. Объем требуемого программного обеспече¬ 
ния оказался относительно небольшим по сравнению с прог¬ 
раммным обеспечением других подобных систем, но существен¬ 
но выше предполагаемого вначале. 

Одним из первых пакетов программного обеспечения систе¬ 
мы SYMBOL был редактор текста, разработка которого обу¬ 
словлена недостатками редактирования, выполняемого аппа¬ 
ратно процессором интерфейса ввода-вывода. Последний обес¬ 
печивает режим редактирования, требующий применения спе¬ 
циальных терминалов, реализует слишком примитивный набор 
функций редактирования и сложен в использовании. Поскольку 
никакие аппаратно реализуемые функции редактирования не 
могут служить как функции встроенных блоков программы-ре¬ 
дактора текста, большая часть процессора интерфейса ввода- 
вывода не используется при работе системы с программой-ре¬ 
дактором. 

Вторым основным пакетом программного обеспечения был 
ориентированный на язык программирования отладчик. Коман¬ 
да SOURCE-POINTER (указание адреса выполняемого опера¬ 
тора исходной программы), рассмотренная в гл. 9, никогда не 
использовалась в системе SYMBOL. Эта команда была вклю¬ 
чена с целью установления связи программных ошибок с соот¬ 
ветствующим оператором исходной программы. К сожалению, 
она оказалась непригодной к использованию и не обеспечива¬ 
ющей результаты, адекватные предъявленным требованиям. 

Ее непригодность связана с тем, что возможны изменения 
(редактирование) исходной программы после выполнения и по¬ 
вторное выполнение текущего объектного кода программы без 
новой трансляции. Редактирование приводит к записи новой 
версии исходной программы в другую область виртуальной па¬ 
мяти. Таким образом, команды SOURCE-POINTER в ранее 
сформированной объектной программе будут задавать ошибоч- 



ные ссылки. Неадекватность результата работы команды предъ¬ 
являемым требованиям проявилась в том, что указывался толь¬ 
ко ошибочный оператор исходной программы, но не определя¬ 
лись более точно операция и операнд, связанные с данной 
ошибкой. 

Одной из наиболее важных функций программы-отладчика 
является декомпилирование объектной программы. При обнару¬ 
жении центральным процессором ошибки в программе управ¬ 
ление автоматически передается отладчику, который, анализи- 

*** EXECUTION ERROR (ZERO DIVISOR - CODE 20) 

IN THE FOLLOWING STATEMENT: 

stl +- qmin * (ml * m2 / (gamma / rho) / (minterm / (l-f)))i 

RIGHT OPERAND: 

I 00 I 
LEFT OPERAND: 
minterm: | -5.663 | 

MONITOR NOW IN CONTROL 
? 

Рис. 10.5. Результаты декомпилирования объектного кода, 
выполненного отладчиком. 

руя объектный код программы, определяет в нем местоположе¬ 
ние команды, с которой связана ошибка, и соседних команд и 
без обращения к исходному тексту программы преобразует 
(декомпилирует) машинные команды в оператор языка SPL. 
Определяя границы искомого фрагмента объектного кода по 
местоположению окружающих его команд END-OF-STATE- 
MENT (конец оператора исходной программы) и используя 
таблицу имен, отладчик в большинстве случаев может точно 
воссоздать оператор языка SPL, за исключением пробелов и 
необязательных круглых скобок. Затем отладчик выводит на 
терминал описание ошибки; декомпилированный оператор; 
стрелку, указывающую на операцию или операнд, связанный с 
ошибкой, и значения операндов операций. Рис. 10.5 демонстри¬ 
рует данные, выводимые отладчиком на терминал. 

Кроме этого, отладчик позволяет отображать (на экране 
дисплея, бумаге и т. п.) значения переменных, выполняемые в 
данный момент операторы языка SPL, а также оператор, вы¬ 
звавший текущую процедуру. 

Сравнительная сложность отладочных функций и простота 
их реализации в системе SYMBOL позволяют сделать вывод о 
важной особенности машин с уменьшенным семантическим 
разрывом между языком программирования и их архитектурой. 
Отладка программ в этом случае упрощается, кроме того, су- 
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щественно снижается стоимость разработки отладочных средств, 
ориентированных на язык программирования. Для сопоставле¬ 
ния с другими системами рассмотрим трудности процесса от¬ 
ладки программ и производства средств их отладки у машин 
низкого уровня ориентации на язык программирования, исполь¬ 
зующих оптимизирующий компилятор, который осуществляет 
значительную реорганизацию программы в процессе генерирова¬ 
ния объектного кода. В этом случае довольно сложно описать со¬ 
отношения между представлениями программы на языке высо¬ 
кого уровня и машинном языке, что в свою очередь еще более 
затрудняет попытки восстановления операторов исходной про¬ 
граммы и локализации в них ошибок по имеющемуся в распо¬ 
ряжении объектному коду этой программы. 

Другие средства программного обеспечения (из числа раз¬ 
работанных для системы SYMBOL) реализуют учетные функ¬ 
ции, выполняемые в начале и конце сеансов связи через тер¬ 
миналы, обслуживают библиотеки подпрограмм и системы 
файлов. Все компоненты программного обеспечения выполня¬ 
ются центральным процессором и конкурируют с другими про¬ 
граммами пользователей за эксплуатацию ресурсов системы. 

Системные программы написаны на так называемой усечен¬ 
ной версии языка SPL. Компилирование с такого языка явля¬ 
ется единственной привилегией и отличием системных программ 
от программ пользователей. Большинство «усеченных» опера¬ 
торов позволяет программе непосредственно запрашивать опе¬ 
рации контроллера памяти (операции, перечисленные в 
табл. 10.2). Примерами «усеченных» операторов являются AG 
(Адресация группы), FF (Выборка и получение адреса следую¬ 
щего слова) и SA (Запись и получение адреса следующего 
слова). 

ОБОБЩЕННАЯ ХАРАКТЕРИСТИКА 
СИСТЕМЫ SYMBOL 

Архитектура и реализация системы SYMBOL имеют важное 
значение во многих отношениях, хотя этой системе и присущи 
некоторые недостатки. Двумя наиболее важными особенностя¬ 
ми системы являются применяемые в ней способы мультипро¬ 
цессорной обработки и управления памятью. Мультипроцессор¬ 
ная организация системы SYMBOL уникальна в том смысле, 
что вместо множества однотипных процессоров общего назначе¬ 
ния она предусматривает использование специализированных 
процессоров, выполняющих разные функции вычислительной си¬ 
стемы. Общепризнанным фактом является то, что специализи¬ 
рованный процессор может быть разработан быстрее и с мень¬ 
шими затратами, чем процессор общего назначения, решающий 
ту же задачу. Специфика механизма управления памятью за- 
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ключается в высокой степени абстракции представления памя¬ 
ти, обеспечиваемого контроллером памяти. Объекты данных с 
более сложной организацией, такие, как стеки, очереди, строки 
переменной длины и списковые структуры, к которым обраща¬ 
ются другие процессоры, легко создаются с помощью операций 
над логической памятью, тем самым уменьшается общий объем 
аппаратных средств управления памятью, необходимых системе. 

Другая важная особенность системы SYMBOL заключается 
в том, что в ней в действительности воплощены принципы ма¬ 
шины языка высокого уровня. Располагая языком SPL и сред¬ 
ствами отладки высокого уровня, пользователь может и не 
знать внутренней организации системы. 

Полностью аппаратная реализация системы, с одной сторо¬ 
ны, является ее достоинством, а с другой стороны, создает оп¬ 
ределенные трудности. Аппаратная реализация супервизора и 
транслятора обеспечивает феноменальную быстроту «трансля¬ 
ции, загрузки и выполнения» программы и большую скорость 
вызова отсутствующих в основной памяти страниц виртуальной 
памяти. Принцип логической памяти был бы неосуществим при 
попытке реализовать его программными средствами. Это демон¬ 
стрирует возможность реализации «на кристалле», т. е. аппа¬ 
ратным путем, функций, традиционно выполняемых с помощью 
программного обеспечения. Однако полностью аппаратная ре¬ 
ализация системы порождает и ряд серьезных проблем, и в ча¬ 
стности большую стоимость внесения в систему изменений и 
расширения реализуемых ею функций. Кроме того, разработчи¬ 
ки выяснили, что при проектировании, основанном на аппарат¬ 
ной реализации функций вычислительной системы, так же не 
избежать ошибок, как и при разработке соответствующего 
программного обеспечения. Однако представляется возможным 
достижение некоторых целей проектирования и разрешения не¬ 
которых проблем благодаря использованию процессоров с мик¬ 
ропрограммным управлением. 

Если говорить об архитектуре центрального процессора, то 
для системы SYMBOL в значительной мере удалось сократить 
семантический разрыв между архитектурой аппаратных средств 
и языком программирования. В архитектуре центрального про¬ 
цессора реализованы самоопределяемые данные, данные пере¬ 
менной длины, десятичная арифметика (см. гл. 4). Существен¬ 
ным недостатком архитектуры, как указано в гл. 9, является 
неэффективное использование памяти машинными командами. 
Отмечалось также, что аппаратно реализуемый транслятор ге¬ 
нерирует объектный код, структура которого далека от опти¬ 
мальной. - 

Изучение производительности центрального процессора по¬ 
казывает, что он весьма эффективен при выполнении сложных 
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операций и совершенно неэффективен при выполнении чаще 
встречающихся простейших операций. Например, операция при¬ 
ращения значения переменной может потребовать до 12 обра¬ 
щений к памяти. Это обусловлено отсутствием адресации в 
командах обращения к стеку, косвенной адресацией посредст¬ 
вом таблицы имен и размещением стека в памяти. 

Основной проблемой, препятствующей использованию си¬ 
стемы SYMBOL в качестве ЭВМ общего назначения, является 
то, что эта система связана с одним языком программирова¬ 
ния, причем новым и незнакомым большинству программистов. 
Одно из решений данной проблемы могло бы заключаться во 
включении в систему нескольких процессоров, выполняющих 
функции трансляторов (например, трансляторов для языков 
SPL, ФОРТРАН, КОБОЛ), однако это представляется неосу¬ 
ществимым из-за сильной ориентации центрального процессора 
на язык SPL. Другим возможным решением является использо¬ 
вание— в добавление к трансляторам для каждого языка — не¬ 
скольких центральных процессоров, каждый из которых был бы 
ориентирован непосредственно на определенный язык програм¬ 
мирования высокого уровня. 

УПРАЖНЕНИЯ 

10.1. Почему в основную шину включены линии МТ? Другими словами, 
почему при выдаче запросов на обращение к памяти в контроллер памяти 
передается информация, идентифицирующая терминалы и пользователей? 

10.2. Центральный процессор часто посылает запрос на выполнение опе¬ 
раций выборки из памяти и просмотра строки в обратном порядке. С какой 
целью это делается? 

10.3. При распределении новых групп слов памяти контроллер памяти ис¬ 
пользует значение счетчика числа первоначально распределенных групп (со¬ 
держимое поля IGAC), что не является более быстрой процедурой, чем вы¬ 
деление групп из списка групп, доступных для распределения. Для чего в 
этом случае используется поле IGAC? 

10.4. Почему слова связи групп слов должны быть связаны между со¬ 
бой? Почему в слово связи группы помещается ссылка на предыдущую груп¬ 
пу списка? 

10.5. Почему для обслуживания регенератора памяти в контроллере па¬ 
мяти предусмотрены специальные операции DL и RG (см. табл. 10.2), хотя 
функции регенератора могли бы быть реализованы и с помощью других опе¬ 
раций контроллера памяти, например SO? 

10.6. Должен ли регенератор памяти просматривать каждую строку для 
нахождения адресов других строк? 

10.7. Каким образом регенератор памяти выделяет адреса среди значений 
данных в процессе просмотра строк? 

10.8. В чем состоит различие между свободной страницей, свободной об¬ 
ластью памяти и списками свободных групп слов? 

10.9. Как изменится нормальная (внутренняя) форма представления 
структуры в результате выполнения оператора присваивания АГ2,2] 

— <1234|4321>;? 

10.10. Почему адреса первых байтов команд и строк имеют вид хх2х 
(см. рис. 9.3 и 9.4), а, например, не ххОх? 



ЧАСТЬ IV 


АРХИТЕКТУРА, ОРИЕНТИРОВАННАЯ 
НА ГРУППУ ЯЗЫКОВ ПРОГРАММИРОВАНИЯ 


ГЛАВА 11 

ВЫЧИСЛИТЕЛЬНАЯ СИСТЕМА В 1700 
ФИРМЫ BURROUGHS 

При разработке вычислительной системы общего назначения 
(т. е. вычислительной системы, обеспечивающей использование 
не одного, а нескольких языков программирования) с архитек¬ 
турой, ориентированной на язык программирования, наиболее 
существенная проблема состоит в том, что значительное сокра¬ 
щение семантического разрыва архитектуры с определенным 
языком программирования приводит к резкому возрастанию 
семантического разрыва этой архитектуры с другими языками. 
Эту проблему иллюстрирует рис. 11.1, на котором представлен 
граф, отражающий семантические различия между языками и 
архитектурами. Пусть семантический разрыв между языком 
программирования и архитектурой машины, реализующей 
средства этого языка, пропорционален длине пути, который 
следует пройти по графу между точками, представляющими 
язык и архитектуру машины. Если некоторая архитектура А1 
ориентирована на язык КОБОЛ, то семантический разрыв меж¬ 
ду этой архитектурой и языком КОБОЛ уменьшается, однако 
семантический разрыв между этой же архитектурой и другими 
языками может оказаться больше, чем при использовании тра¬ 
диционной архитектуры фон Неймана. 

Два решения этой проблемы представляются очевидными. 
Первое заключается в создании архитектуры, которая отобра¬ 
жалась бы на графе (рис. 11.1) справа от точки представления 
архитектуры фон Неймана, но не настолько далеко от нее, что¬ 
бы оказаться ориентированной в сильной степени на какой-ни¬ 
будь определенный язык. Другими словами, подобная архитек¬ 
тура должна соответствовать тому, что есть общего в семан¬ 
тике языков программирования. Второе решение предполагает 
построение системы, реализующей одновременно несколько ар¬ 
хитектур (например, за счет использования нескольких процес¬ 
соров или динамической перестройки архитектуры системы). 
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каждая из которых ориентирована на определенный язык про¬ 
граммирования. Примером последного подхода в указанной про¬ 
блеме является семейство ЭВМ В1700 фирмы Burroughs. 


КОБОЛ 



Рис. 11.1. Графическое представление семантических разрывов 
между языками программирования и архитектурой 
вычислительных машин. 


АРХИТЕКТУРА СИСТЕМЫ В1700 
ФИРМЫ BURROUGHS 

В отличие от систем, рассмотренных в предыдущих главах, 
ЭВМ В1700 представляет собой реальную вычислительную си¬ 
стему, используемую для решения экономических задач. По 
производительности эта машина относится к классу малых и 
средних ЭВМ, предоставляя в распоряжение пользователя язы¬ 
ки программирования БЕЙСИК, ФОРТРАН, КОБОЛ и РПГ/2. 
Система В1700 — это семейство шести совместимых процессо¬ 
ров, отличающихся друг от друга быстродействием и объемом 
памяти. Две более поздние разработки подобных систем — 
В1800 и В1900 — имеют такую же архитектуру, но в них вклю¬ 
чена мультиобработка и повышено быстродействие схемной ло¬ 
гики и обращения к памяти. Система В1700 является мульти¬ 
программной вычислительной системой с виртуальной памятью 
и может применяться для телеобработки и работы с базами 
данных. 

Ознакомление с архитектурой системы В1700 лучше всего 
начать с анализа ее работы в мультипрограммном режиме. 
Предположим, что в стадии выполнения в системе находятся 
программа на КОБОЛе и программа на ФОРТРАНе, причем в 
данный момент функционирует операционная система В1700, на¬ 
зываемая МСР (Master Control Program — Главная управляю¬ 
щая программа). Последняя определяет, выполнение какой 
прикладной программы должно быть возобновлено. 



Главная управляющая программа написана на языке SDL 
(System or Software Development Language — Язык разработки 
программного обеспечения), подобном языкам АЛГОЛ и ПЛ/1. 
В поисках архитектуры, оптимальной для выполнения програм¬ 
мы МСР, разработчики системы создали специальную архитек¬ 
туру, ориентированную в высокой степени на язык SDL. Сле¬ 
довательно, в данный момент процессор имеет именно такую 
архитектуру. 

Разработчики сознавали, однако, что архитектура, ориенти¬ 
рованная на язык SiDL, плохо подходит для выполнения при¬ 
кладных программ (поскольку существует большой семантиче¬ 
ский разрыв между этой архитектурой и программами, напи¬ 
санными на языках БЕЙСИК* ФОРТРАН, КОБОЛиРПГ). Для 
решения данной проблемы была разработана система, исполь¬ 
зующая несколько архитектур, каждая из которых ориентиро¬ 
вана на определенный язык программирования и реализуется 
отдельной микропрограммой. Если Главная управляющая про¬ 
грамма устанавливает, что за определенный интервал времени 
должно быть возобновлено выполнение программы на языке 
КОБОЛ, то она указывает реализующим ее аппаратным сред¬ 
ствам на необходимость переключения микропрограммы (в дан¬ 
ном случае на включение микропрограммы, ориентирующей си¬ 
стему на язык КОБОЛ). Эта операция полностью изменяет ар¬ 
хитектуру вычислительной машины, обеспечивая работу про¬ 
цессора с совершенно другим набором команд и другими фор¬ 
мами представления данных. 

Теперь машина возобновляет выполнение программы на язы¬ 
ке КОБОЛ, прошедшей на предыдущем этапе стадию компили¬ 
рования в объектную программу, которая соответствует архи¬ 
тектуре, ориентированной на язык КОБОЛ. Объектный код, со¬ 
ответствующий каждой подобной архитектуре системы, называ¬ 
ется S -языком. Предположим, что произошло прерывание вво¬ 
да-вывода. Текущая микропрограмма переключается на микро¬ 
программу, ориентированную на язык SDL, и начинает выпол¬ 
няться Главная управляющая программа. Если эта программа 
решает, что должно быть возобновлено выполнение программы 
на языке ФОРТРАН, то, установив факт компилирования про¬ 
граммы на предыдущем этапе и тем самым преобразования ее 
в программу на соответствующем (другом) S -языке, она указы¬ 
вает текущей микропрограмме на необходимость переключения 
на микропрограмму, ориентированную на ФОРТРАН. В резуль¬ 
тате архитектура системы оказывается ориентированной на язык 
ФОРТРАН. 

Итак, система В1700 динамически изменяет свою архитекту¬ 
ру во время диспетчеризации различных прикладных программ, 
осуществляемой Главной управляющей программой. Для каж- 
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дого языка программирования, кроме КОБОЛа и РПГ, си¬ 
стема В1700 располагает отдельным S -языком. Поскольку КО¬ 
БОЛ и РПГ семантически подобны, программы, написанные на 
этих языках, транслируются на один и тот же S -язык. 

РЕАЛИЗАЦИЯ АРХИТЕКТУРЫ СИСТЕМЫ 

Хотя вопросы проектирования процессоров преднамеренно ис¬ 
ключены из данной книги, сама природа архитектуры системы 
В 1700, ориентированной на группу языков программирования, 
порождает ряд проблем, связанных с созданием процессора, 
реализующего эту архитектуру. Поэтому целесообразно хотя бы 
кратко рассмотреть решение этих проблем. 

Одной из проблем является выбор оптимального размера 
слова памяти и разрядности трактов передачи данных, посколь¬ 
ку эти параметры обычно тесно связаны с размерами полей 
представления данных в машине определенной архитектуры, 
а система В1700 объединяет в себе несколько архитектур раз¬ 
личного назначения. Например, если архитектура процессора 
ориентирована на язык ФОРТРАН, оптимальная длина слова 
составляет 18 или 36 бит, однако такой размер может оказать¬ 
ся слишком большим при ориентации архитектуры на КОБОЛ, 
поскольку в этом случае желательно иметь машину с байто¬ 
ориентированным представлением десятичных чисел. 

Решение данной проблемы заключалось в обеспечении ди¬ 
намического изменения основных характеристик процессора 
при изменении его архитектуры. Например, в системе преду¬ 
смотрено динамическое изменение разрядности АЛУ процессо¬ 
ра. Если архитектура процессора ориентирована на язык ФОРТ¬ 
РАН, то АЛУ работает с данными, представляемыми 18-бито- 
выми словами. Когда архитектура процессора перестраивается 
на язык КОБОЛ, то данные представляются как 8-битовые сло¬ 
ва или слова, длина которых кратна 8 бит. Динамическое изме¬ 
нение разрядности осуществляется с помощью внутреннего ре¬ 
гистра, в который микропрограмма записывает требуемую раз¬ 
рядность АЛУ. Если содержимое этого регистра равно 16, АЛУ 
выполняет операции над 16-битовыми операндами. Физически 
разрядность АЛУ фиксированна (24 бит). Однако указанный 
выше регистр маскирует ненужные АЛУ разряды, создавая впе¬ 
чатление, что оно имеет динамически изменяемую разрядность. 

Такая же проблема имеет место при работе с памятью; 
в одних случаях требуется адресация памяти словами длиной 
18 бит, в других случаях — словами длиной 8 бит. Решение 
проблемы в данном случае состояло в обеспечении возможно¬ 
сти адресации к каждому биту памяти и указании длины адре¬ 
суемых полей в интерфейсе, связывающем процессор с памятью. 
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Если, например, микропрограмме необходимо адресоваться к 
16-битовым словам памяти, то при запросе разрешения на за¬ 
пись данных в память эта микропрограмма указывает адрес со¬ 
ответствующего бита, устанавливает длину адресуемого поля 
(слова) равной 16 бит и передает 16-битовые данные. 

Еще одной проблемой создания процессора, реализующего 
архитектуру В1700, является большой объем управляющей па¬ 
мяти, требуемой для хранения нескольких микропрограмм. Од¬ 
нако, во-первых, эта проблема является не такой серьезной, как 
это кажется на первый взгляд, поскольку основная часть каж¬ 
дой микропрограммы (исключая средства отладки) занимает 
~28 000 бит памяти (менее чем 2000 16-битовых микрокоманд). 
Во-вторых, разработчик системы располагает несколькими воз¬ 
можностями. Имеется микрокоманда пересылки данных из ос¬ 
новной в управляющую память, что позволяет хранить микро¬ 
программы в основной памяти и вызывать их страницы в управ¬ 
ляющую память по мере необходимости. Кроме того, можно ор¬ 
ганизовать выборку микрокоманд процессором непосредствен¬ 
но из основной памяти, хотя машина в этом случае будет ра¬ 
ботать медленнее вследствие большего времени доступа к ос¬ 
новной памяти. В системе В1800 отсутствует управляющая па¬ 
мять; вместо этого необходимые сегменты микропрограммы вы¬ 
зываются отдельными страницами в высокоскоростную кэш-па¬ 
мять. Модели малой производительности систем В1700 и В1800 
не имеют ни управляющей памяти, ни кэш-памяти; микрокоман¬ 
ды выбираются процессором из основной памяти. 

ПАМЯТЬ И ПРОИЗВОДИТЕЛЬНОСТЬ 

Как отмечалось в части I книги, основное преимущество исполь¬ 
зования архитектуры высокого уровня заключается в сущест¬ 
венном уменьшении количества битов, необходимых для пред¬ 
ставления программы. Это наглядно демонстрирует работа си¬ 
стемы В1700. Согласно результатам исследования [1], семь те¬ 
стовых программ на языке ФОРТРАН занимали 280К байт в си¬ 
стеме В1700, 560Кбайт — в Системе 360и450К байт — в системе 
В3500 фирмы Burroughs, т. е. по сравнению с последними дву¬ 
мя системами объем израсходованной памяти в системе В1700 
составил 50 и 38% соответственно. Средний объем 20 тестовых 
программ на языке КОБОЛ составил 450К байт в системе В1700 
и 1490К байт — в Системе 360. Таким образом, в данном случае 
выигрыш равен 70%. Тридцать одна тестовая программа на 
языке РПГ/2 имела среднюю длину 150К байт в системе В1700 
и 310К байт в Системе ІВМ/3, т. е. экономия памяти составила 
52%. 

В части I книги также указывалось, что для архитектуры 
высокого уровня характерно существенное повышение произво- 
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дительности. Об этом свидетельствуют данные о времени вы¬ 
полнения ориентированной на числовые расчеты программы на 
языке РПГ: 25 с при использовании системы В1700 и 208 с — 
для модели 10 Системы ІВМ/3. В относительных единицах это 
составит соответственно 8: 1 [1]. Однако система В1700 на 
~75% дороже. В результате соотношение обобщенных показа¬ 
телей «стоимость — производительность» становится равным 
5:1. Хотя среднее время выполнения команды системы В1700 с 
архитектурой, ориентированной на язык РПГ, равно 35 мкс, 
а команды Системы ІВМ/3 составляет 6 мкс, при работе си¬ 
стемы В1700 требуется значительно меньшее количество команд 
(примерно в 50 раз). 
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ГЛАВА 12 

АРХИТЕКТУРА ЭВМ СИСТЕМЫ В1700 
ФИРМЫ BURROUGHS, 

ОРИЕНТИРОВАННАЯ НА ЯЗЫКИ КОБОЛ И РПГ 

Поскольку архитектура системы В1700 динамически перестраи¬ 
вается, можно говорить о наличии архитектуры стольких типов, 
сколько языков программирования допускает к использованию 
система. Ограничимся здесь рассмотрением архитектуры толь¬ 
ко одного типа, а именно той, на которую настраивается систе¬ 
ма для выполнения программ, транслируемых с языков КОБОЛ 
и РПГ [1]. 

При создании архитектуры этого типа стремились минимизи¬ 
ровать ее семантический разрыв с языками КОБОЛ и РПГ; в ре¬ 
зультате большинство операторов языка КОБОЛ транслируется 
в машинные команды «один-к-одному». В соответствии с основ¬ 
ными положениями гл. 4 архитектура предполагает использо¬ 
вание самоопределяемых (теговых) данных, дескрипторов объ¬ 
ектов «составные данные», стеков для управления подпрограм¬ 
мами, ячеек памяти переменной длины и десятичной арифмети¬ 
ки. Набор команд процессора, реализующего данную архитек¬ 
туру, не ориентирован на размещение операндов в стеке или 
регистрах; для обращения к операндам используется адреса¬ 
ция типа «память —память». Адресация лексического уровня 
не предусмотрена (она была бы бесполезной для программ на 
КОБОЛе и РПГ); вместо этого память адресуется путем ука¬ 
зания имени сегментов памяти и смещения в пределах сегмен¬ 
та— способом, широко используемым в вычислительных систе¬ 
мах фирмы Burroughs и являющимся примитивным предше¬ 
ственником потенциальной адресации. 

В предыдущих главах анализ архитектуры вычислительных 
систем сопровождался примерами. Подобная методика непри¬ 
менима к архитектуре В1700, ориентированной на языки КО¬ 
БОЛ и РПГ, поскольку в данном случае отсутствует достаточ¬ 
ный объем информации об организации памяти и как следст¬ 
вие невозможно проиллюстрировать вид объектной программы, 
исходный текст которой написан на языке КОБОЛ или РПГ. 
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ТИПЫ ДАННЫХ 

В рассматриваемой архитектуре предусмотрены четыре основ¬ 
ных типа данных: строка числовых данных без знака, состоя¬ 
щая из десятичных цифр, каждая из которых представлена 
4 бит (4-битовые десятичные цифры); строка числовых данных 
со знаком, состоящая из 4-битовых десятичных цифр; строка 
8-битовых символов без знака и строка 8-битовых символов со 
знаком. Если строка содержит данные со знаком, то первые 4 
или 8 бит представляют знак (+ или —). Когда данные без 
знака участвуют в арифметических операциях, предполагается, 
что они представляют собой положительные величины. Если 
результат арифметической операции описан как данные без 
знака, то в память записывается его абсолютная величина. 

Числовые данные (строки 4-битовых десятичных цифр) всег¬ 
да имеют определенное числовое значение, представленное в 
двоично-десятичном коде. Максимальная длина числовых дан¬ 
ных— 4095 цифр, не считая знака числа. 

Символьные данные (строки 8-битовых символов) представ¬ 
ляются в коде EBCDIC. (Они могут также записываться и в 
коде ASCII, однако обсуждение представления данных в этом 
коде здесь не приводится.) Если представленные таким обра¬ 
зом данные имеют числовые значения (т. е. если все байты стро¬ 
ки, за исключением байта знака, содержат двоичный код 
llllxxxx, где хххх — двоично-десятичное представление циф¬ 
ры), то они могут использоваться в качестве операндов арифме¬ 
тических операций. Максимальная длина символьных данных — 
1023 символа, не считая знака. 

Поскольку используются данные, записываемые в память 
вместе со своими тегами (указателями типа), обрабатывающие 
их машинные команды носят универсальный, не зависящий от 
типа данных характер, причем соответствующее преобразова¬ 
ние данных осуществляется автоматически. Например, один из 
исходных операндов команды ADD (СЛОЖЕНИЕ) может быть 
строкой из четырех 4-битовых десятичных цифр со знаком, дру¬ 
гой операнд — строкой из пяти 8-битовых символов без знака 
(при условии, что все символы — десятичные цифры), резуль¬ 
тат сложения — строкой из семи 8-битовых символов со зна¬ 
ком. 

Последним типом данных является массив — однородный на¬ 
бор одного из четырех типов данных. Могут использоваться 
одно-, двух- и трехмерные массивы. Максимальный размер мас¬ 
сива числовых данных — 524 287 цифр, массива символьных 
данных —262 143 символа. Машина обеспечивает автоматиче¬ 
ское индексирование элементов массивов присвоением или вы¬ 
числением соответствующих индексов — индексирование при- 
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своением и индексирование вычислением. Если одним из операн¬ 
дов команды является массив, то машина автоматически опре¬ 
деляет местоположение соответствующего элемента массива. 
Команда может задавать значения индексов явно (в операндах 
команды) либо индексы могут быть заданы неявно (находиться 
в дескрипторе массива). 

ПАРАМЕТРЫ ПРОГРАММЫ 

Одно из уникальных свойств данной архитектуры состоит в том, 
что размеры отдельных полей команд и дескрипторов (т. е. ад¬ 
реса памяти) могут изменяться от программы к программе, хо¬ 
тя для любой конкретной программы эти размеры фиксирован¬ 
ны. Это позволяет успешно решать наиболее критичную зада¬ 
чу, с которой приходится иметь дело разработчику ЭВМ: опре¬ 
деление размера адресных полей. В машинах, архитектура ко¬ 
торых предполагает фиксированный размер адресных полей, 
для одних программ этот размер оказывается излишне боль¬ 
шим, и как следствие имеет место непроизводительный рас¬ 
ход памяти. Для других программ размер адресных полей не¬ 
допустимо мал, так что для преодоления этого недостатка тре¬ 
буется применение сложной системы адресации, в Системе 370, 
например, использование нескольких регистров базы. 

В рассматриваемой архитектуре компилятор выбирает ми¬ 
нимальные размеры адресных полей, достаточные для записи 
адресов в конкретной объектной программе. Затем он выпол¬ 
няет трансляцию программы с учетом этих размеров и сообща¬ 
ет их процессору путем запоминания параметров программы 
вместе с ее объектным кодом. Эти параметры программы, пояс- 


Таблица 12.1. Параметры программы 


Параметр 

ское’обозна- 

Размер 

Диапазон 

Длина поля, содержащего имя сег- 




мента данных 

PSEG 

5 

0-18 

Длина поля, содержащего смещение 




данных в сегменте 

PDISP 

5 

1-21 

Размер поля, содержащего длину 



1—14 

данных 

PCELL 

5 

Длина индекса дескриптора 

PINDEX 

5 

1-31 

Длина дескриптора 

Длина поля, содержащего смещение 

PDESC 

6 

6-57 

адреса перехода, увеличенного на 1 

PBDISP 

5 

2-31 

Длина стека подпрограмм 

Смещение нулевой области сегмен¬ 

PSSIZE 

5 

1-31 

тов данных программы 

PDSEGZ 

24 

Любой 

Смещение стека подпрограмм 

PSTACK 

24 

» 

Смещение таблицы дескрипторов 

PDTAB 

24 

* 
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няемые в следующих разделах, перечислены в табл. 12.1, где 
указаны длина полей, занимаемых каждым параметром, и 
диапазон допустимых значений параметра. Значения всех па¬ 
раметров задаются положительными двоичными числами без 
знака. 

Для иллюстрации использования двух параметров отметим, 
что адреса памяти состоят из имени сегмента и смещения. Если 
для конкретной программы PSEG = 00110 2 (6 Ш ), a PDISP = 
= 011002 (12ю), то адреса этой программы задаются 6-битовым 
именем сегмента и 12-битовым смещением. В машинных коман¬ 
дах, однако, адреса в таком виде не записываются. 

СТРУКТУРА ПАМЯТИ 

С каждой объектной программой связана служебная область 
памяти, показанная на рис. 12.1. Эта область адресуется с по¬ 
мощью регистра базы и содержит информацию о состоянии 


\Тавлица редактирования (8 сим¬ 
волов лредст.-ых !-6итоВьтц подами) 


Специальные регистры 


Управляющие символы иден¬ 
тификаторов данных _ 


Область данных, 
размещаемых с перекрытием' 


Информация о состоянии, 


PSTACK 

- 

' PSTACK +PSSIZE , 


Рис. 12.1. Служебная 

область памяти в 

системе В 1700 (архитектура, 

ориентированная 

на язык КОБОЛ). 


программы и областях хранения данных. Машинные команды и 
переменные программы размещаются в двух или более отдель¬ 
ных сегментах памяти. 
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Таблица редактирования содержит восемь специальных сим¬ 
волов, используемых при выполнении некоторых команд редак¬ 
тирования. Таблица дескрипторов включает дескрипторы дан¬ 
ных для каждой переменной программы. Это аналог таблицы 
имен, используемой в системе SYMBOL. В области масок ре¬ 
дактирования находятся подкоманды редактирования, на кото¬ 
рые ссылаются команды редактирования. Область нулевого 
сегмента данных содержит информацию для управления про¬ 
граммой и данные, используемые при взаимодействии приклад¬ 
ной программы с Главной управляющей программой. В стеке 


< 

сегмента 

Смещение 

Длина 

данных 

і Tun s 

Р данных т 

4 




о 


PSEG PDISP PCELL 1 2 1 

Размеры I . 

полей I 

Н- PDESC - 

Рис. 12.2. Формат дескриптора скалярных данных. 

подпрограмм хранится информация о каждой активной в дан¬ 
ный момент подпрограмме. 

Таблица дескрипторов, называемая в ЭВМ фирмы Burro¬ 
ughs таблицей СОР (current operand table — таблица текущих 
значений операндов), содержит по одному элементу для каж¬ 
дой переменной программы. Машинные команды обращаются к 
своим операндам путем указания индексов дескрипторов, нахо¬ 
дящихся в этой таблице, которые в свою очередь задают ме¬ 
стоположение самих данных. Индекс первого элемента таблицы 
равен 1. 

Формат дескриптора скалярных данных (не являющихся 
элементами массива) показан на рис. 12.2. Первые два поля 
содержат адрес данных в памяти: имя сегмента, в котором на¬ 
ходятся данные, и смещение (выраженное количеством 4-би¬ 
товых полей) первого бита данных от начала сегмента. Третье 
поле определяет длину данных без учета знака (если он име¬ 
ется), задаваемую количеством 4-битовых цифр или 8-битовых 
символов в зависимости от типа данных. Поля смещения и дли¬ 
ны содержат двоичные числа без знака. В этом дескрипторе 
бит SIF (subscript-index flag) — флажок присваивания/вычисле¬ 
ния индекса равен 0, а это означает, что описываемые дескрип¬ 
тором данные скалярного типа. 

Содержимое поля типа данных определяет тип данных: 

00 —числовые данные без знака; 

01 —символьные данные без знака; 
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10—числовые данные со знаком; 

11 — символьные данные со знаком. 

Флажок ASCII указывает, в каком коде представлены сим¬ 
вольные данные — в коде ASCIJL или EBCDIC. Этот флажок 
влияет на выполнение некоторых машинных команд; в даль¬ 
нейшем будут рассматриваться данные, представленные толь¬ 
ко в коде EBCDIC. 

Массивы данных описываются расширенным дескриптором, 
показанным на рис. 12.3. Такие дескрипторы занимают не од¬ 
но, а несколько слов таблицы дескрипторов. Седьмое по поряд- 


Имя 

S 

Смещение ’ 


А 

S 

с 

!« 

S 

[масштаб -1 Масштаб- 
\ный мно- \ный мно- 

Масштаб¬ 

Граница 

массива 



шх 

1 

2. 

!і 


' 


окитель 3 


PSEG 

PDISP PCELL 1 

2 

1 

2 

1 

PDISP 

PDISP 

1 PDISP 

PDISP 









1_ Поле присутствіе 


торе, если массив 
трехмерный 


I —Поле присутствует в дескрип¬ 
торе, если массив двумерный 

Рис. 12.3. Формат дескриптора массива. 

ку поле определяет размерность массива (количество одновре¬ 
менно присваиваемых или вычисляемых индексов элемента мас¬ 
сива). Поле SI указывает, какой тип индексирования исполь¬ 
зуется — присваиванием или вычислением. (Различия между ука¬ 
занными выше двумя типами индексирования массивов описы¬ 
ваются в документации по языку КОБОЛ.) Если задано индек¬ 
сирование присваиванием, то от одного до трех полей, следую¬ 
щих за полем SI, содержат двоичные величины, представляю¬ 
щие собой масштабные множители, на которые должны умно¬ 
жаться значения каждого индекса для определения местополо¬ 
жения требуемого элемента массива. Поле границы массива 
содержит смещение последнего элемента массива. Если вычис¬ 
ленное смещение элемента массива оказывается больше, чем ве¬ 
личина, находящаяся в этом поле, то генерируется сообщение об 
ошибке. Например, для массива размером 3X4 ссылка на эле¬ 
мент массива 4,2 не будет восприниматься как ошибочная, 
а ссылка на элемент 4,4 сопровождается указанием на этот эле¬ 
мент как на ошибочный. 

Правила организации индексированных массивов таковы, 
что за дескриптором массива должны непосредственно следо¬ 
вать от одного до трех дескрипторов каждого присваиваемого 
или вычисляемого индекса. Эти дескрипторы имеют структуру 
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дескрипторов скалярных данных. Следовательно, обрабатывая 
ссылку на дескриптор массива, процессор может определить 
местоположение текущих значений индексов и использовать эти 
величины для' вычисления адреса текущего элемента массива. 


ФОРМАТ КОМАНД 

Каждая машинная команда состоит из кода операции OP (ope¬ 
ration code), за которым следует несколько других полей, коли¬ 
чество которых определяется типом команды. В этих полях 


ссылки на дескриптор (DR) 



обычно находятся литеральные данные или индексы дескрипто¬ 
ров. Коды операции представляются 3 или 9 бит. Семь наибо¬ 
лее часто используемых команд: INCREMENT — ПРИРАЩЕ¬ 
НИЕ, MOVE ALPHANUMERIC — ПЕРЕСЫЛКА СИМВОЛЬ¬ 
НЫХ ДАННЫХ, MOVE NUMERIC -ПЕРЕСЫЛКА ЧИСЛО- 
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ВЫХ ДАННЫХ, BRANCH — ПЕРЕХОД, PERFORM ENTER — 
ВЫПОЛНЕНИЕ ПРОЦЕДУРЫ, COMPARE ALPHANUMERIC 
— СРАВНЕНИЕ СИМВОЛЬНЫХ ДАННЫХ, COMPARE 
NUMERIC — СРАВНЕНИЕ ЧИСЛОВЫХ ДАННЫХ —имеют 
3-битовые коды операций; коды операций остальных команд 
записываются с помощью 9 бит в формате Шхххххх. 

За несколькими ниже рассматриваемыми исключениями 
поля команды могут содержать ссылку на дескриптор (DR — 
descriptor reference), литеральные данные либо ссылку на дес¬ 
криптор (LJT/DR — literat or descriptor reference) или адрес пе¬ 
рехода (BA —branch address). Форматы команд показаны на 
рис. 12.4. Например, в поле DR может находиться индекс эле¬ 
мента таблицы дескрипторов или встроенный дескриптор. Ин¬ 
дексы дескрипторов — это двоичные числа без знака. Встроен¬ 
ные дескрипторы для скалярных величин имеют тот же самый 
формат, что и дескрипторы, размещаемые в таблице дескрип¬ 
торов, тогда как формат встроенных дескрипторов массивов не¬ 
сколько отличен. Вместо того чтобы в этом случае повторять 
запись дескрипторов значений индексов за встроенным дескрип¬ 
тором массива, в данный дескриптор помещаются индексы дес¬ 
крипторов полей, в которых находятся дескрипторы значений 
индексов элементов массива. 

Поле, обозначенное как LIT/DR, может содержать лите¬ 
ральные данные или адрес дескриптора. Для литералов, со¬ 
стоящих менее чем из восьми цифр или символов (не считая 
знака), используются укороченная форма представления, а ли¬ 
тералов большей длины — расширенная форма. Литералы мо¬ 
гут быть числовыми или символьными данными со знаком или 
без знака. 

Поле, обозначенное как ВА (адрес перехода), используется 
в командах перехода. Если осуществляется переход на выполне¬ 
ние объектного кода, находящегося в текущем сегменте, то при¬ 
меняется формат, соответствующий переходу внутри сегмента. 
При этом величина смещения — это двоичное число без знака, 
задающее смещение двоичного представления команды относи¬ 
тельно начала сегмента. 

МАШИННЫЕ КОМАНДЫ 

В рассматриваемой архитектуре предусмотрено выполнение 
38 команд, которые по функциональному назначению могут 
быть объединены в следующие группы: арифметических опера¬ 
ций, пересылки, управления и другого назначения. Семь команд 
арифметических операций обеспечивают обработку операндов 
любого из четырех возможных типов данных; при необходимо¬ 
сти выполняется автоматическое преобразование данных и при- 
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соединение ведущих нулей. Если исходными операндами команд 
арифметических операций являются символьные данные, то их 
представление в коде EBCDIC должно соответствовать число¬ 
вой величине (например, с точки зрения выполнения арифмети¬ 
ческих операций коды F0F5 (5) и 43F3F2 (+32) представляют 
корректные данные, а код А1ВС — некорректные). 

Одиннадцать команд пересылки данных перемещают дан¬ 
ные из одного поля в другое, выполняя в то же время явно или 
неявно заданные операции редактирования. Шестнадцать 
команд управления используются для изменения последователь¬ 
ности выполнения машинных команд. Четыре команды послед¬ 
ней группы команд предназначены для обращения прикладной 
программы к Главной управляющей программе (например, для 
выполнения операций ввода-вывода). 

АРИФМЕТИЧЕСКИЕ ОПЕРАЦИИ 

Имя команды. INCREMENT (двухадресная операция сложе¬ 
ния) 

Выполняемая операция. Первый операнд добавляется ко второ¬ 
му. 

Формат. OP, LIT/DR, DR 

Имя команды. ADD (трехадресная операция сложения) 
Выполняемая операция. Суммируются значения двух операн¬ 
дов и результат помещается в поле, адресуемое третьим опе¬ 
рандом. 

Формат. OP, LIT/DR, DR, DR 

Операнды. Первые два операнда могут задавать одну и ту же 
строку цифр или символов, однако третий операнд должен быть 
ссылкой на другую строку. 

Имя команды. INCREMENT-BY-ONE 

Выполняемая операция. Приращение величины, адресуемой опе¬ 
рандом, на 1. 

Формат. OP, DR 

Имя команды. SUBTRACT 

Выполняемая операция. Первый операнд вычитается из второ¬ 
го, и результат помещается в поле, адресуемое третьим опе¬ 
рандом. 

Формат. OP, LIT/DR, DR, DR 
Имя команды. DECREMENT 

Выполняемая операция. Уменьшение на 1 величины, адресуе¬ 
мой операндом. 

Формат. OP, DR 
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Имя команды. MULTIPLY 

Выполняемая операция. Умножение двух операндов и запись 
результата операции в поле, адресуемое третьим операндом. 
Формат. OP, LIT/DR, DR, DR 

Операнды. Третий операнд должен быть определен как число¬ 
вые данные со знаком или без знака. 

Имя команды. ШѴШЕ 

Выполняемая операция. Деление второго операнда на первый. 
Частное записывается по адресу третьего операнда, остаток — 
по адресу второго операнда. 

Формат. OP, LIT/DR, DR, DR 

Операнды. Знак остатка совпадает со знаком делимого (второ¬ 
го операнда). Попытка деления на нуль приводит к установке 
признака переполнения. 

команды пересылки ДАННЫХ 

Имя команды. MOVE ALPHANUMERIC 

Выполняемая операция. Первый операнд пересылается в поле, 
адресуемое вторым операндом. Если первый операнд представ¬ 
ляет собой числовые данные, значение пересылаемых данных 
преобразуется в код EBCDIC 
Формат. OP, LIT/DR, DR 

Операнды. Если длина второго операнда (принимающего поля) 
больше длины первого операнда (посылающего поля), то пере¬ 
даваемые данные дополняются справа пробелами (если это 
символьные данные) или нулями (если это числовые данные). 
Если длина посылающего поля больше длины принимающего 
поля, то производится усечение передаваемых данных справа. 
Если в посылающем поле находятся числовые данные, то каж¬ 
дая передаваемая десятичная цифра записывается в принимаю¬ 
щем поле в виде llllxxxx, за исключением знака. Если имеет¬ 
ся знак, он преобразуется в соответствующее представление в 
коде EBCDIC. 

Имя команды. MOVE NUMERIC 

Выполняемая операция. Первый операнд пересылается по ад¬ 
ресу второго операнда. 

Формат. OP, LIT/DR, DR 

Операнды. При необходимости выполняется надлежащее преоб¬ 
разование данных. Если второй операнд (принимающее поле) 
определен как данные без знака, то знак первого операнда (по¬ 
сылающего поля) игнорируется. Если принимающее поле име¬ 
ет большую длину, чем посылающее поле, то передаваемые дан¬ 
ные дополняются слева нулями, если меньшую — то произво¬ 
дится усечение передаваемых данных слева. 
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Имя команды. MOVE SPACES 

Выполняемая операция. Поле, адресуемое операндом, заполня¬ 
ется пробелами, представленными в коде EBCDIC (0100 0000 2 ) 
Формат. OP, DR 

Операнды. Операнд должен быть определен как символьные 
данные без знака. 

Имя команды. MOVE ZEROS 

Выполняемая операция. Поле, адресуемое операндом, заполня¬ 
ется нулями. 

Формат. OP, DR 

Операнды. Если операнд определен как данные со знаком, то 
записывается знак положительного числа. 

Имя команды. MOVE TRANSLATE 

Выполняемая операция. Первый операнд пересылается по ад¬ 
ресу второго операнда с перекодировкой каждого символа с по¬ 
мощью специальной таблицы перекодировки. 

Формат. OP, LIT/DR, DR, DR 

Операнды. Первый и второй операнды должны быть определены 
как символьные данные без знака. Третий операнд указывает 
таблицу перекодировки. Перекодировка осуществляется следую¬ 
щим образом: числовое значение каждого передаваемого сим¬ 
вола, умноженное на 8, используется в качестве смещения от¬ 
носительно начала таблицы перекодировки. В принимающее по¬ 
ле пересылается символ, находящийся в таблице перекодировки 
по вычисленному таким образом адресу. Если принимающее по¬ 
ле имеет большую длину, чем посылающее поле, то данные в 
принимающем поле дополняются справа пробелами; в против¬ 
ном случае производится усечение справа. 

Имя команды. SCALED MOVE NUMERIC 
Выполняемая операция. Числовые данные из поля, адресуемого 
первым операндом команды, пересылаются в поле, адресуемое 
вторым операндом. Предварительно к длине посылающего поля 
добавляется или из нее вычитается масштабный множитель. 
Формат. OP, LIT/DR, DR, V, SCL 

Операнды. Поле V содержит единственный бит. Поле SCL со¬ 
держит двоичную величину без знака, количество битов кото¬ 
рой равно параметру PCELL. Если Ѵ=0, то содержимое поля 
SCL (масштабный множитель) добавляется к длине посылаю¬ 
щего поля, причем предполагается, что расширенное таким об¬ 
разом посылающее поле дополнено справа нулями. Значение 
масштабного множителя не должно превышать длину посылаю¬ 
щего поля. Если Ѵ= 1, то содержимое поля SCL вычитается из 
длины посылающего поля. Значение масштабного множителя 
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не должно превышать длину поля — источника данных. После 
модификации с помощью масштабного множителя длины пере¬ 
сылаемых данных команда выполняется так же, как и команда 
MOVE NUMERIC. 

Имя команды. CONCATENATE 

Выполняемая операция. Содержимое каждого из указанных в 
команде посылающих полей пересылается в принимающее 
поле. 

Формат. OP, N, DR, LIT/DR1,...,LIT^DRN 

Операнды. N — 4-битовое двоичное число без знака, указываю¬ 
щее количество посылающих полей. Следующее поле команды 
содержит адрес дескриптора принимающего поля. Остальные N 
полей команды определяют посылающие поля. Данные пересы¬ 
лаются в соответствии с правилами выполнения команды MOVE 
ALPHANUMERIC. 

Имя команды. EDIT 

Выполняемая операция. Первый операнд пересылается по ад¬ 
ресу второго операнда; пересылка осуществляется под управ¬ 
лением строки подкоманд, находящейся по указанному адресу. 
Формат. OP, LIT/DR, DR, DADDR 

Операнды. DADDR — двоичное число без знака (с числом би¬ 
тов, равным параметру PDISP), определяющее смещение стро¬ 
ки подкоманд редактирования относительно начала нулевой об¬ 
ласти сегментов данных; в табл. 12.2 приведены эти подкоман¬ 
ды, размещаемые в области «маски редактирования», показан¬ 
ной на рис. 12.1. Если длина адресата операции превышает 
длину поля — источника данных, адресат дополняется слева ну¬ 
лями. Если длина адресата меньше длины поля — источника 
данных, производится усечение данных слева. Посылающее по¬ 
ле может содержать данные любого типа, однако адресат дол- 
бен быть определен как символьные данные без знака. 

Подкоманды. Коды подкоманд команды EDJT приведены в 
табл. 12.2, где nnnn — 4-битовое двоичное число, используемое 
в качестве счетчика повторений. Например, величина 0000 озна¬ 
чает, что повторения не производится, т. е. операция выполня¬ 
ется только один раз; величина 0010 указывает на повторение 
выполнения подкоманды дважды, хххх — 4-битовое двоичное 
число без знака, указывающее количество пропускаемых пози¬ 
ций в поле адресата. Величина 0000 указывает на то, что про¬ 
пуска позиций нет. уууу — индекс элемента таблицы символов 
редактирования (табл. 12.3). Если имеет место соотношение 
уууу — 1010, то это означает, что символ редактирования запи¬ 
сан непосредственно за данной подкомандой, а за ним следует 
очередная подкоманда. 
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Таблица 12.2. Подкоманды редактирования 


Код под¬ 
команды 

Назначение 

OOOOnnnn 

Пересылка цифр (MOVE DIGITS) 

0001 nnnn 

Пересылка символов (MOVE CHARACTERS) 

OOlOnnnn 

Пересылка с подавлением ведущих полей (MOVE SUP¬ 
PRESS) 

Заполнение символами подавления ведущих нулей (FILL 
SUPPRESS) 

OOllnnnn 

OlOOxxxx 

Смещение по полю адресата в обратном направлении (SKIP 
REVERSE DESTINATION) 

OlOlyyyy 

Безусловное включение символа редактирования (INSERT 
UNCONDITIONALLY) 

OllOyyyy 

Включение символа редактирования, если установлен признак 
отрицательного числа (INSERT ON MINUS) 

Olllyyyy 

Включение символа редактирования, если установлен признак 
подавления ведущих нулей (INSERT SUPPRESS) 

lOOOyyyy 

Включение символа редактирования и пересылка цифры или 
символа данных (INSERT FLOAT) 

lOOlyyyy 

Включение символа редактирования (END FLOAT MODE) 

1010 0000 

Завершение редактирования, если пересылается не нуль (END 
NONZERO) 

Завершение редактирования (END OF MASK) 

1010 0001 

1010 0010 

Установка признака подавления ведущих нулей (START 
ZERO SUPPRESS) 

Формирование дополнения признака защиты данных 
(COMPLEMENT CHECK PROTECT) 

1010 0011 

Другие коды 

Не определено 


Во время выполнения операции редактирования процессор 
использует три переключателя: S (знак), Z (подавление веду¬ 
щих нулей) и Р (защита данных). В начале выполнения коман¬ 
ды EDJT переключатели Z и Р установлены в 0. Переключа¬ 
тель S устанавливается в 0, если посылающее поле содержит 
положительную величину (или величину без знака), в против¬ 
ном случае этот переключатель устанавливается в 1. 

Имя подкоманды. MOVE DIGIT 

Выполняемая операция. Переключатель Z устанавливается в I. 
Очередная цифра или символ посылающего поля пересылается 
в следующую позицию поля адресата. Если пересылается циф¬ 
ра (4-битовые данные), то производится ее преобразование в 
код EBCDIC. Если пересылается символ (8-битовые данные), 
то его первые 4 бит в поле адресата устанавливаются равны¬ 
ми 1111. 

Имя подкоманды. MOVE CHARACTER 

Выполняемая операция. Переключатель Z устанавливается в 1. 
Очередная цифра или символ посылающего поля пересылается 
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Таблица 12.3. Стандартные символы 
редактирования 


Номер элемента (ин¬ 
декс) таблицы редак¬ 
тирования 

Символ, включаемый в 
поле адресата команды 
редактирования 

0 

+ 

2 

• 

3 


4 


5 

$ 

6 

0 

7 

Пробел 

8 

+ или — 

9 

Пробел или — 

10 

Встроенный 8-битовый 
символ 


в следующую позицию поля адресата. Если пересылается циф¬ 
ра, то производится ее преобразование в код EBCDIC. 

Имя подкоманды. MOVE SUPPRESS 

Выполняемая операция. Если очередная цифра или символ по¬ 
сылающего поля не представляют собой 0 или если значение 
переключателя Z равно 1, то выполняется операция пересылки 
цифры. В противном случае в следующую позицию поля ад¬ 
ресата записывается пробел, если значение переключателя Р 
равно 0, или знак звездочки (*), если значение переключателя 
Р равно 1. 

Имя подкоманды. FILL SUPPRESS 

Выполняемая операция. Если значение переключателя Р рав¬ 
но 0, в следующую позицию поля адресата записывается про¬ 
бел; в противном случае — знак звездочки. В счетчике цифр 
или символов посылающего поля приращения не производится. 

Имя подкоманды. SKIP REVERSE DESTINATION 
Выполняемая операция. Величина nnnn вычитается из счетчи¬ 
ка, указывающего очередную позицию поля адресата. Содер¬ 
жимое счетчика цифр или символов посылающего поля прира¬ 
щения не получает. 

Имя подкоманды. INSERT UNCONDITIONALLY 
Выполняемая операция. Указанный символ редактирования, 
находящийся в таблице символов редактирования или являю¬ 
щийся встроенным, записывается в следующую позицию поля 
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адресата. Если в подкоманде номер элемента таблицы редакти¬ 
рования равен 8, то при S=0 записывается знак «+>, а при 
S = 1 — знак «—>. Если номер элемента таблицы редактирова¬ 
ния равен 9, то в следующую позицию поля адресата при S = 0 
записывается пробел, а при S = 1 —знак «—». Содержимое 
счетчика позиций посылающего поля приращения не получает. 

Имя подкоманды. INSERT ON MINUS 

Выполняемая операция. В следующую позицию поля адресата 
записывается определенный символ редактирования, выбирае¬ 
мый с учетом приведенных ниже условий. Содержимое счетчика 
позиций посылающего поля приращения не получает. 


S = 1; 

Т = 0,..., 7 

Запись символа, находящегося 
в таблице редактирования под 
номером Т 

S = 0; 

Р = 0 

Запись пробела 

S = 0; 

Р=1 

Запись знака «*» 

S = l; 

Т = 8 

Запись знака «—» 

S = 1; 

Т=9 

Запись знака «—» 

S = 1: 

Т=10 

Запись встроенного символа 
редактирования 


Имя подкоманды. INSERT SUPPRESS 

Выполняемая операция. В следующую позицию поля адресата 
записывается определенный символ редактирования, выбирае¬ 
мый с учетом приведенных ниже условий. Содержимое счетчика 
позиций посылающего поля приращения не получает. 


Z = 1; 

Т = 0, 

..., 7 

Запись символа, находящегося в таб¬ 
лице редактирования 

Z = 0; 

Р = 0 


Запись пробела 

Z = 0; 

Р=1 


Запись знака «*» 

2=1; 

S = 0; 

Т = 8 

Запись знака «+» 

2=1; 

S = 1; 

Т = 8 

Запись знака «—» 

2=1; 

S = 0; 

Т=9 

Запись пробела 

2=1; 

S = 1; 

Т=9 

Запись знака «—» 

Z = 1; 

Т = 10 


Запись встроенного символа 
редактирования 


Имя подкоманды. INSERT FLOAT 

Выполняемая операция. В следующую одну или две позиции 
поля адресата записываются указанный символ редактирования 
и (или) производится пересылка очередной цифры или символа 
посылающего поля. Выполнение операции зависит от следующих 
условий (SRC — очередная цифра или символ посылающего 
поля): 
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Z=1 

Z=0; SRC = 0; 
Z = 0; SRC=0; 
Z = 0; SRC=£0; 

P = 0 
P = 1 
T=0 

.7 

Пересылка цифры 

Запись пробела 

Запись знака «*» 

Запись символа, находяще¬ 

Z = 0; SRC=/=0; 

T = 8 

S = 0 

гося в таблице редактирова¬ 
ния под номером Т; затем 
пересылка цифры 

Запись знака «+»; затем 

Z = 0; SRC=/=0; 

T=8; 

S = 1 

пересылка цифры 

Запись знака «—»; затем 

Z = 0; SRC^O; 

T=9; 

S=0 

пересылка цифры 

Запись пробела; затем пе¬ 

Z=0; SRC=^0; 

T=9; 

S=1 

ресылка цифры 

Запись знака «—»; затем 

Z=0; SRC=t^0; 

T=10 

пересылка цифры 

Запись встроенного символа 


редактирования; затем пе¬ 
ресылка цифры 


Имя подкоманды. END FLOAT MODE 

Выполняемая операция. В следующую позицию поля адресата 
записывается определенный символ редактирования, выбирае¬ 
мый с учетом приведенных ниже условий. Содержимое счетчи¬ 
ка позиций посылающего поля приращения не получает. 


N 

О 

Ч 

II 

о 

.,7 

Запись символа, находящего¬ 
ся в таблице редактирования 
под номером Т 

Z = 0; Т=8; 

S=0 

Запись знака «=> 

Z=0; Т=8; 

S = 1 

Запись знака «—» 

Z = 0; Т = 9; 

S = 0 

Запись пробела 

Z=0; Т=9; 

S = 1 

Запись знакіа «—» 

Z = 0; Т= 10 


Запись встроенного символа 
редактирования 

Z = 1 


Подкоманда не выполняет ни¬ 
какой операции 


Имя подкоманды. END NONZERO 

Выполняемая операция. Выполнение команды EDIT заверша¬ 
ется, если произошла пересылка любой, отличной от нуля циф¬ 
ры или символа посылающего поля. В противном случае вы¬ 
полняется следующая подкоманда. 

Имя подкоманды. END OF MASK. 

Выполняемая операция. Завершение выполнения команды EDIT. 
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Имя подкоманды. START ZERO SUPPRESS 
Выполняемая операция. Переключатель Z устанавливается рав¬ 
ным 0. 

Имя подкоманды. COMPLEMENT CHECK PROTECT 
Выполняемая операция. Формируется дополнение значения пе¬ 
реключателя Р. 

Имя подкоманды. EDIT WITH EXPLICIT, MASK 
Выполняемая операция. Первый операнд пересылается в поле, 
адресуемое вторым операндом; пересылка осуществляется под 
управлением встроенной в команду строки подкоманд. 

Формат. OP, LIT/DR, DR, строка подкоманд 
Операнды. Строка подкоманд имеет тот же формат, что и ли¬ 
теральные данные (см. рис. 12.4). Первые 2 бит (поле типа) 
должны быть равны 01. Если следующие 3 бит (поле длины) 
не равны 0, они указывают длину следующих за ними лите¬ 
ральных данных (строки подкоманд). Если эти 3 бит равны 0, 
то следующие за ними 8 бит задают длину литеральных дан¬ 
ных (строки подкоманд), расположенных непосредственно за 
этими битами. К использованию операндов применимы соответ¬ 
ствующие правила выполнения команды EDIT. 

Подкоманды. Используется тот же набор подкоманд, что и при 
выполнении команды EDIT. Различие между этими двумя 
командами состоит в том, что в данном случае подкоманды 
встроены непосредственно в команду EDIT-WITH-EXPLICIT 
MASK, тогда как при использовании команды EDIT под¬ 
команды записываются отдельно от команды. 

Имя команды. MICR EDIT 

Выполняемая операция. Первый операнд пересылается в поле, 
адресуемое вторым операндом. Определенные символы исклю¬ 
чаются (не пересылаются), причем количество переданных сим¬ 
волов помещается в поле, адресуемое третьим операндом. 
Формат. OP, RD, DR, DR 

Операнды. Команда предназначена для обработки данных при 
использовании устройства считывания знаков, нанесенных «маг¬ 
нитными чернилами»; детали выполнения операции здесь не об¬ 
суждаются. 

Имя команды. MICR FORMAT 

Выполняемая операция. Первый операнд пересылается и разме¬ 
щается в определенном формате в поле, адресуемом вторым 
операндом. 

Формат. OP, DR, DR 
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Операнды. Команда предназначена для обработки данных при 
использовании устройства считывания знаков, нанесенных «маг¬ 
нитными чернилами»; детали выполнения операции здесь не об¬ 
суждаются. 

КОМАНДЫ УПРАВЛЕНИЯ 

Имя команды. BRANCH 

Выполняемая операция. Управление передается команде с ука¬ 
занным адресом. 

Формат. OP, ВА (см. рис. 12.4) 

Имя команды. COMPARE ALPHANUMERIC 
Выполняемая операция. Каждый бит первого операнда сравни¬ 
вается с соответствующим битом второго операнда. Если вы¬ 
полняется заданное в команде условие, то управление переда¬ 
ется команде, находящейся по указанному адресу. 

Формат. OP, LIT/DR, DR, R, ВА 

Операнды. R представляет собой 3-битовое поле, задающее сле¬ 
дующие операции сравнения операндов: 001 (>), 010 (<), 
011 (=й=), 100 ( = ), 101 (>или=) и ПО (< или =). 

Имя команды. COMPARE NUMERIC 

Выполняемая операция. Первый операнд сравнивается со вто¬ 
рым как числовые величины. Если выполняется заданное в 
команде условие, то управление передается команде, находя¬ 
щейся по указанному адресу. 

Формат. OP, LIT/DR, DR, R, ВА 

Операнды. Поле R используется так же, как и в команде COM¬ 
PARE ALPHANUMERIC. 

Имя команды. COMPARE REPEAT 

Выполняемая операция. Производится последовательное срав¬ 
нение битов первого операнда с битами сегментов второго опе¬ 
ранда. Если выполняется заданное в команде условие, то 
управление передается команде, находящейся по указанному 
адресу. 

Формат. OP, LITyiDR, DR, R, ВА 

Операнды. Оба сравниваемых операнда должны быть опреде¬ 
лены как символьные данные без знака. Длина поля, адресуе¬ 
мого вторым операндом, должна быть кратна длине поля, ад¬ 
ресуемого первым операндом. Поле R используется так же, как 
и в команде COMPARE ALPHANUMERIC. 

Имя команды. COMPARE FOR SPACES 

Выполняемая операция. Операнд сравнивается бит за битом с 
содержимым поля, заполненного одними пробелами. Если вы- 
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полняется заданное в команде условие, то управление передает¬ 
ся команде, находящейся по указанному адресу. 

Формат. OP, DR, R, ВА 

Операнды. Операнд должен быть определен как символьные 
данные без знака. Поле R используется так же, как и в команде 
COMPARE ALPHANUMERIC. 

Имя команды. COMPARE FOR ZEROS 

Выполняемая операция. Операнд сравнивается с содержимым 
поля, заполненного нулями, по правилам сравнения числовых 
величин. Если заданное в команде условие выполняется, управ¬ 
ление передается команде, находящейся по указанному адресу. 
Формат. OP, DR, R, ВА 

Операнды. Поле R используется так же, как и в команде 
COMPARE ALPHANUMERIC. 

Имя команды. COMPARE FOR GLASS 

Выполняемая операция. Анализируется формат операнда. Если 
он соответствует формату, заданному в команде, управление пе¬ 
редается команде, находящейся по указанному адресу. 

Формат. OP, DR, С, ВА 

Операнды. Содержимое 2-битового поля С задает требуемую 
проверку принадлежности операнда к определенному классу 
данных: 00 (только буквы), 01 (только цифры), 10 (не только 
буквы), 11 (не только цифры). Операнд должен быть опреде¬ 
лен как символьные данные. 

Имя команды. BRANCH ON OVERFLOW 

Выполняемая операция. Проверяется наличие признака пере¬ 
полнения, и при его обнаружении управление передается коман¬ 
де, находящейся по указанному адресу. 

Формат. OP, V, ВА 

Операнды. V—1-битовое поле. Переход выполняется, если Ѵ= 
= 1 и признак переполнения установлен в 1 либо Ѵ=0 и признак 
переполнения установлен в 0. 

Имя команды. SET OVERFLOW 

Выполняемая операция. Явная установка в 1 или сброс призна¬ 
ка переполнения. 

Формат. OP, V 

Операнды. V—1-битовое поле. Содержимое этого поля при¬ 
сваивается биту признака переполнения. (Признак переполне¬ 
ния устанавливается в 1 неявным образом в результате деле¬ 
ния на 0.) 

Имя команды. GO ТО DEPENDING ON 

Выполняемая операция. Управление передается по одному из 
нескольких адресов в зависимости от значения операнда. 
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Формат. OP, DR, N, В AO, BA1,...,BAN 

Операнды. N — 10-битовое двоичное число без знака. Если опе¬ 
ранд меньше 1 или больше N, то в качестве адреса перехода 
используется содержимое поля ВАО. Если значение операнда 
принадлежит диапазону от 1 до iN, то операнд используется в 
качестве индекса для определения соответствующего адреса 
перехода. 

Имя команды. ALTER 

Выполняемая операция. В указанную область памяти записыва¬ 
ется адресная константа. 

Формат. OP, DADDR, ВА 

Операнды. DADDR — двоичное число без знака (с числом би¬ 
тов, равным параметру PDISP), определяющее смещение ад¬ 
ресуемой области относительно начала нулевого сегмента дан¬ 
ных служебной области программы; начало этого сегмента за¬ 
дается значением параметра PDSEGZ. Содержимое поля ВА 
(адрес перехода) записывается в указанную область памяти. 

Имя команды. ALTERED GO ТО PARAGRAPH 
Выполняемая операция. Управление передается команде, нахо¬ 
дящейся по указанному адресу. В качестве адреса перехода ис¬ 
пользуется адресная константа, выбираемая из памяти. 
Формат. OP, DADDR 

Операнды. DADDR — это двоичное число без знака (с числом 
битов, равным параметру PDISP), определяющее смещение ад¬ 
ресуемой области относительно начала нулевого сегмента дан¬ 
ных служебной области программы; начало этого сегмента за¬ 
дается значением параметра PDSEGZ. Адрес перехода, запи¬ 
санный в этой области, определяет местоположение команды, 
которой передается управление. 

Имя команды. PERFORM ENTER 

Выполняемая операция. Слово, содержащее имя сегмента с те¬ 
кущей командой, смещение следующей команды относительно 
начала сегмента и константу, загружается в стек подпрограмм; 
управление передается команде, находящейся по указанному ад¬ 
ресу. 

Формат. ОР, К, ВА 

Операнды. Поле К содержит 8-битовую константу. 

Имя команды. PERFORM EXIT 

Выполняемая операция. Если константа, содержащаяся в слове, 
находящемся на вершине стека, совпадает со значением, за¬ 
данным в команде, то управление возвращается на выполнение 
команды, адресуемой этим словом. В противном случае про- 
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должается выполнение команд, следующих за командой 
PERFORM EXIT. 

Формат. OP, К 

Операнды. Поле К содержит 8-битовую константу. Если имеет 
место совпадение констант, то слово, находящееся на вершине 
стека, изымается из стека. 

Имя команды. ENTER 

Выполняемая операция. Слово, содержащее имя сегмента с те¬ 
кущей командой и смещение относительно начала сегмента сле¬ 
дующей команды, подлежащей выполнению, загружается в стек 
подпрограмм; управление передается команде, находящейся по 
указанному адресу. 

Формат. OP, ВА 

Имя команды. EXIT 

Выполняемая операция. Управление возвращается команде, ука¬ 
зываемой словом, находящимся на вершине стека. Это слово 
изымается из стека. 

Формат. ОР 


ПРОЧИЕ КОМАНДЫ 

Имя команды. CONVERT 

Выполняемая операция. Операнд преобразуется в 24-битовое 
двоичное число без знака и записывается в указанную ячейку 
нулевого сегмента данных служебной области программы. 
Формат. OP, DR, DADDR 

Операнды. Операнд должен быть положительным десятичным 
числом, которое преобразуется в двоичное число и записывается 
по адресу, задаваемому полем DADDR. Это поле содержит 
двоичное число без знака (с числом битов, равным параметру 
PDISP), определяющее смещение адресата операции относи¬ 
тельно начала нулевого сегмента данных служебной области 
программы; начало этого сегмента определяется параметром 
PDSEGZ. 

Имя команды. COMMUNICATE 

Выполняемая операция. Длина и абсолютный адрес операнда 
записываются в общий для данной программы и Главной управ¬ 
ляющей программы буфер адреса сообщения. Управление пе¬ 
редается Главной управляющей программе. 

Формат. OP, DR 

Операнды. Перед записью в буфер длина операнда преобразует¬ 
ся из двоично-десятичного или символьного представления в 
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двоичное число. Абсолютный адрес операнда в двоичной фор¬ 
ме также записывается в буфер. 

Имя команды. LOAD COMMUNICATE 

Выполняемая операция. Последние 24 бит информации в общем 
для данной программы и Главной управляющей программы бу¬ 
фере адреса сообщения помещаются в указанную ячейку ну¬ 
левого сегмента данных. 

Формат. OP, DADDR 

Имя команды. MAKE PRESENT 

Выполняемая операция. Загружается указанный сегмент дан¬ 
ных. Адрес области данных (определяемой относительно ее ба¬ 
зы) помещается в указанную ячейку нулевого сегмента дан¬ 
ных. 

Формат. OP, SEG, DADDR 

Операнды. Поле SEG, длина которого равна параметру PSEG, 
указывает имя сегмента данных. 

УПРАЖНЕНИЯ 

12.1. Какое значение параметра PINDEX (размер поля индексов дескрип¬ 
торов) должно использоваться транслятором, если для выполнения програм¬ 
мы, написанной на языке КОБОЛ, требуется таблица дескрипторов, состоя¬ 
щая из 43 слов? 

12.2. Каким должен быть размер команды выполнения двухадресной опе¬ 
рации сложения (INCREMENT), если первый операнд не литерал? 

12.3. Каким должен быть ‘размер команды INCREMENT, увеличивающий 
на 2 значение переменной? 

12.4. Расшифруйте следующую команду MOVE ALPHANUMERIC (пер¬ 
вые 3 бит —код операции; предполагается, что параметр PINDEX=6): 
0001000100111001101011 

12.5. Что записывается в поле адресата команды, приведенной в п. 12.4, 
если адресат определен как символьные данные без знака длиной в 3 сим¬ 
вола? 

12.6. Что записывается в 10-символьное поле адресата команды EDIT, 
если посылающее поле содержит шестнадцатеричную величину 00001045, а 
строка подкоманд имеет вид: 

10100011 01010101 00100101 01010011 00000001 10100001? 

12.7. Какие атрибуты набора команд архитектуры, ориентированной на 
язык КОБОЛ, являются наиболее оригинальными? Почему? 

12.8. Напишите небольшую программу на языке КОБОЛ и выполните ее 
трансляцию «вручную» (на бумаге) для последующего выполнения этой прог¬ 
раммы машиной с рассматриваемой архитектурой (т. е. сформируйте дескрип¬ 
торы, параметры программы и поток машинных команд). 
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ЧАСТЬ V 

АРХИТЕКТУРА, ОРИЕНТИРОВАННАЯ 
НА ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ЭВМ 


ГЛАВА 13 

НАЗНАЧЕНИЕ АРХИТЕКТУРЫ СИСТЕМЫ SWARD 

Следующей подлежит рассмотрению архитектура вычислитель¬ 
ной системы SWARD (SoftWARe-orienteD machine — машина, 
ориентированная на программное обеспечение). Единственной 
целью создания такой экспериментальной машины было выяс¬ 
нение возможности разработки архитектуры вычислительной 
системы, аппаратные средства которой реализуют большую 
часть функций системы, связанных с организацией и выполне¬ 
нием программ, т. е. функции программного обеспечения маши¬ 
ны. Важность этой цели определяется тем, что наиболее суще¬ 
ственным недостатком современных вычислительных систем и 
программных средств является большая стоимость разработки 
надежных программ. Много усилий затрачено на разработку 
проектов программного обеспечения, которые позволяли бы 
ликвидировать этот недостаток. Здесь можно назвать и созда¬ 
ние принципов более эффективной разработки программ, совер¬ 
шенствование приемов и методологии тестирования, разработку 
языков программирования, обеспечивающих написание про¬ 
грамм, менее подверженных ошибкам, развитие математических 
методов доказательства корректности программ. Однако прило¬ 
женные усилия не привели к существенному сдвигу в направ¬ 
лении решения указанной проблемы. К тому же проблема раз¬ 
работки дешевого и надежного программного обеспечения 
осложняется следующими дополнительными факторами: 

1) повышенными требованиями к точности и надежности 
функционирования программ в новых важных сферах приме¬ 
нения программного обеспечения, таких, как управление воз¬ 
душными и космическими полетами, системы медицинского об¬ 
служивания, банковские системы с обработкой данных в опера¬ 
тивном режиме, системы управления в реальном масштабе вре¬ 
мени и др. 

2) нехваткой квалифицированных программистов, что ощу¬ 
щается сейчас и прогнозируется на ближайшее будущее. 
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Несмотря на определенные успехи, достигнутые в техноло¬ 
гии разработки программного обеспечения, можно отметить и 
следующие недостатки: 

1) производительность труда в программировании не увели¬ 
чилась сколько-нибудь заметно, и стоимость разработки про¬ 
грамм не претерпела изменений, сравнимых с изменением стои¬ 
мости аппаратных средств вычислительных систем (например, 
стоимость написания одной команды для микропроцессора 
обычно превышает стоимость самого процессора); 

2) при разработке стандартного программного обеспечения 
свыше 50% расходов приходится на организацию процедур 
тестирования и отладки; 

3) равное 1/20 отношение числа ошибок при разработке 
программного обеспечения и написания прикладных программ 
к общему числу операторов не является, к сожалению, нетипич¬ 
ным. 

В связи с изложенным выше становится ясно, почему была 
предпринята попытка подойти к решению проблемы с другой 
стороны — попытаться модифицировать архитектуру машины, 
являющуюся аппаратной поддержкой средств традиционного 
программного обеспечения. 

Первоначально принципы этой архитектуры были сформули¬ 
рованы в работе [1], а затем описаны в первом издании дан¬ 
ной книги. С тех пор рассматриваемая архитектура претерпела 
существенные изменения і[2, 3] и была реализована в аппа¬ 
ратном виде в Институте системных исследований фирмы IBM. 

Идея создания архитектуры, повышающей надежность раз¬ 
рабатываемых программ, не является новой, но SWARD — пер¬ 
вая система, в которой осуществляется попытка всестороннего 
охвата подлежащих решению проблем. Предшествующие рабо¬ 
ты в этом направлении имели значительно более частный ха¬ 
рактер. Можно, например, отметить работы [4, 5], в которых 
предлагался вариант машины и архитектуры операционной си¬ 
стемы для определения некоторых типов программных ошибок 
(ошибок адресации). В этой системе любое обращение к па¬ 
мяти выполняется косвенным образом через дескриптор, опре¬ 
деляющий положение и размер области памяти, ее содержи¬ 
мое и предоставляемые ей «привилегии» доступа (некоторая 
разновидность потенциальной адресации). Однако в програм¬ 
мах на языках высокого уровня подобные средства защиты мо¬ 
гут оказаться полезными только для устранения небольшой ча¬ 
сти всех возможных ошибок. В работе і[6], посвященной архи¬ 
тектуре машин и отладке программ, показаны преимущества 
вычислительной системы, аппаратные средства которой опозна¬ 
ют данные с неопределенными значениями, используют теги, де¬ 
лающие слова памяти самоопределяемыми, проверяют количе- 
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ство и тип фактических параметров при обращениях к процеду¬ 
рам. В работе [7] отмечаются достоинства средств обнаруже¬ 
ния ошибок и отладки программ, используемых машинами с те¬ 
говой организацией памяти. Другие исследователи [8] указы¬ 
вают на целесообразность снабжения машины (на уровне ап¬ 
паратных средств) информацией о всех возможных последова¬ 
тельностях вызова модулей. Это позволит выявлять ошибки, 
приводящие к неправильной последовательности вызова моду¬ 
лей. Указывалось также на то, что процесс отладки мог бы 
стать более эффективным, если бы система сохраняла инфор¬ 
мацию о нескольких последних выполнявшихся командах или 
переходах в программе [9]. Автор работы \[10] высказывает 
мнение в более общей форме о том, что значительные сдвиги 
в разработке больших программ могут произойти только при 
существенных изменениях структуры аппаратных средств (ма¬ 
шины), и в частности отмечает преимущества использования 
одноуровневой памяти. 

ЦЕЛИ СОЗДАНИЯ НОВОЙ АРХИТЕКТУРЫ 

Знакомство с системой SWARD можно было бы начать с рас¬ 
смотрения ее архитектуры, однако без определения основных 
целей ее создания многие характеристики этой архитектуры 
оставались бы неясными. Поэтому прежде всего проанализиру¬ 
ем цели проектирования, приведшие к появлению этой системы. 

Побудительным мотивом к поиску новых решений было 
стремление усовершенствовать процесс разработки программ 
(системных и прикладных) и повысить их надежность при вы¬ 
полнении. При этом выдвигалось требование принципиального 
подобия языков программирования, используемых для написа¬ 
ния таких программ, тем языкам, которые получили наиболь¬ 
шее распространение в настоящее время. Можно сказать, что 
цель заключалась в создании более благоприятной среды для 
программистов и корректных программ, которая в то же время 
была бы неподходящей для программ с ошибками. Было сфор¬ 
мулировано шесть основных требований, которым должна удов¬ 
летворять новая система: 

1) обнаружение семантических ошибок в программах; 

2) ограничение последствий возможных ошибок в програм¬ 
мном обеспечении; 

3) усовершенствование процесса проектирования програм¬ 
много обеспечения и приемов программирования; 

4) упрощение процесса разработки программ; 

5) более эффективное тестирование и отладка за счет спе¬ 
циальных средств разработки и сопровождения программного 
обеспечения; 
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6) упрощение структуры двух традиционно наиболее слож¬ 
ных видов программного обеспечения — операционных систем 
и компиляторов. 

Для удовлетворения первого требования введена классифи¬ 
кация семантических ошибок по 37 различным типам. В отли¬ 
чие от логической ошибки семантическая ошибка характеризу¬ 
ется допущенными в программе нарушениями семантических 
спецификаций используемого языка. (Заметим, что многие ло¬ 
гические ошибки приводят к семантическим.) Было принято 
решение о том, что в общем случае эти ошибки не могут быть 
выявлены на этапе компилирования. Однако из этого не следу¬ 
ет, что компиляторы принципиально не могут в ряде случаев 
обнаруживать ошибки такого рода. Дело в том, что компиля¬ 
торы просто не способны обнаруживать все ошибки каждого 
из этих типов. Перечислены некоторые основные типы семанти¬ 
ческих ошибок: 

1. Обращение к переменной, значение которой в данный мо¬ 
мент не определено (или не установлено). Это может быть про¬ 
стая переменная, элемент массива, часть (поле) записи или 
структуры, адрес, элемент в цепочке знаков и т. д. Анализ дан¬ 
ных указывает на то, что ошибки этого типа являются наибо¬ 
лее распространенными. 

2. Обращение к элементу массива с указанием индекса это¬ 
го элемента, выходящего за пределы данного массива. 

3. Обращение посредством переменной, используемой в ка¬ 
честве указателя, ссылки или для разрешения доступа, к части 
памяти, не предназначенной для хранения данных. 

4. Обращение посредством переменной типа «указатель» 
к части памяти, уже освобожденной программой. 

5. Присвоение значению переменного типа или атрибута, от¬ 
личного от того, который ожидает компилятор. Например, про¬ 
грамма читает данные из файла и обращается к отдельным по¬ 
лям каждой записи в соответствии с определением последней, 
в то время как фактическое представление данных в записи мо¬ 
жет оказаться несоответствующим определению записи. 

6. Количество фактических параметров, передаваемых про¬ 
цедуре, не равно ожидаемому количеству, т. е. числу ее фор¬ 
мальных параметров. 

7. Типы передаваемых фактических параметров отличаются 
от типов соответствующих формальных параметров процедуры. 

8. Несоответствие определений глобальных переменных в 
разных модулях. 

9. Данные, адресуемые переменной типа «указатель», не 
имеют атрибутов, которые ожидает компилятор (например, ука¬ 
зателю, используемому в программе на языке ПЛ/Ідля бази¬ 
рования одной структуры данных, может быть присвоен адрес 
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другой структуры, а затем этот указатель попытаются исполь¬ 
зовать для обращения к данным первой структуры). 

10. Модификация процедурой входного фактического пара¬ 
метра (значение которого изменению не подлежит). 

Немаловажным является вопрос о том, сколь значительно 
число разнообразных ошибок, действительно имеющих место в 
программах. Данные работы '[1] позволяют подтвердить обос¬ 
нованность проведенной классификации ошибок. Так, в выбор¬ 
ке из 39 ошибок, допущенных в программном обеспечении реше¬ 
ния аэрокосмических задач и задач обработки информации в 
реальном масштабе времени, 13 ошибок относятся к выделен¬ 
ным здесь типам семантических ошибок. Анализ 3361 ошибок 
программирования, обнаруженных при работе с большой систе¬ 
мой контроля и управления, показывает, что по крайней мере 
487 ошибок приходится на перечисленные выше типы ошибок. 
В упомянутой работе также отмечено, что обнаружение ошибок 
этих типов требует определенных усилий в том смысле, что не 
все из них выявляются на первоначальных стадиях отладки. 

Хотя зависимости между типом ошибки и сложностью ее 
отыскания не установлены, тем не менее можно отметить, что 
ошибки выделенных типов относятся к ошибкам, обнаруживае¬ 
мым с наибольшими затратами усилий. Частично это объясня¬ 
ется способностью таких ошибок придавать недетерминирован¬ 
ный характер работе программы. 

Второе требование, предъявляемое к рассматриваемой архи¬ 
тектуре, касается способности системы ограничивать послед¬ 
ствия допущения ошибок. Для достижения этого требуется вы¬ 
полнение пяти условий, связанных с системой адресации и за¬ 
щиты памяти от несанкционированного доступа. Одно из них, 
например, заключается в том, чтобы ошибка в данной програм¬ 
ме (прикладной или системной) не вызывала непредусмотрен¬ 
ных изменений в другой программе или в обрабатываемых ею 
данных. Согласно другому условию, системные программы (на¬ 
пример, операционная система) не должны обладать возмож¬ 
ностью неявной адресации к прикладным программам или об¬ 
рабатываемым ими данным. Имеется также условие, в соот¬ 
ветствии с которым необходимо, чтобы ошибки в программном 
модуле не могли приводить к изменению данных, не предназна¬ 
ченных для использования данным модулем. Иначе говоря, ад¬ 
ресное пространство модуля должно быть ограничено его соб¬ 
ственными локальными переменными и параметрами, т. е. дол¬ 
жен быть реализован принцип разбиения всего адресного про¬ 
странства на небольшие области санкционированного доступа. 
Третье требование, предъявляемое к рассматриваемой архитек¬ 
туре, сводится к обеспечению возможности применения совре¬ 
менных прогрессивных методов проектирования и разработки 
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программ. Перечислим некоторые условия реализации этого 
требования. 

1. Наличие эффективных средств разработки и выполнения 
программ с большим числом модулей. 

2. Отказ от использования глобальных переменных и ана¬ 
логичных способов адресации данных, например типа неявно 
заданного совместного использования переменных вложенными 
процедурами. Отметим, что это требование, по существу, сво¬ 
дится к отказу от использования в архитектуре многоуровневой 
лексической адресации. 

3. Отказ от программирования на языке ассемблера. 

4. Возможность работы с абстрактными, определяемыми 
пользователем типами данных. 

5. Ориентация на работу со структурированными програм¬ 
мами; наличие в мониторах средств синхронизации обработки 
программных модулей. 

Четвертое требование предполагает упрощение процесса раз¬ 
работки программ благодаря закладываемым в систему прин¬ 
ципам ее организации и их влиянию на языки программирова¬ 
ния. Данное и предыдущее требования к архитектуре преследу¬ 
ют такую цель, как создание условий для предупреждения 
ошибок программирования. Большинство условий, удовлетво¬ 
ряющих этим требованиям, были сформулированы в процессе 
разработки данной архитектуры, а не заблаговременно. Часть 
этих условий касается упрощенного представления операций 
ввода-вывода, способов независимого определения данных в про¬ 
граммах, более упорядоченных форм сообщений об ошибках и 
использования простых принципов взаимосвязи программ и 
данных. 

Пятое требование, предъявляемое к архитектуре вычисли¬ 
тельной системы, предполагает придание ей таких свойств, ко¬ 
торые поддерживают и благоприятствуют функционированию 
средств тестирования и отладки, снижая прямые и накладные 
расходы на их проведение. Допустимо, в частности, предполо¬ 
жить, что аппаратные средства системы могут способствовать 
выполнению следующих функций тестирования и отладки: 

1) трассировки выполнения команд программы; 

2) трассировки последовательности вызова процедур; 

3) формирования таблиц частоты выполнения отдельных 
операторов программы; 

4) трассировки выполнения команд перехода; 

5) определения местоположения обнаруженных ошибок и 
выполнения некоторых действий по их исправлению. 

Шестое требование к архитектуре предполагает такую орга¬ 
низацию последней, которая позволила бы упростить структу¬ 
ру компиляторов и операционных систем. Это возможно при 
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сокращении семантического разрыва между языком программи¬ 
рования и архитектурой машины, а также при наличии таких 
базовых механизмов операционной системы, как механизмы 
управления и синхронизации параллельных процессов. 

СРАВНЕНИЕ СИСТЕМ 
ПО ИХ СПОСОБНОСТИ 
ОБНАРУЖИВАТЬ ОШИБКИ 

Основная цель, выдвигавшаяся при разработке системы SWARD, 
заключалась в создании более благоприятных условий для 
выявления семантических ошибок в программах. Вот почему 
небезынтересно выяснить, как обнаружение таких ошибок вы¬ 
полняется в других системах. Для целей сравнения было вы¬ 
брано 22 наиболее распространенных типа семантических оши¬ 
бок (остальные типы ошибок встречаются крайне редко или 
характерны только для отдельных языков программирования). 

При этом было бы естественно рассматривать те вычисли¬ 
тельные машины, которые широко используются в настоящее 
время. Однако в основном они соответствуют традиционной 
модели фон Неймана, а поскольку известно, что машинами с 
такой архитектурой большая часть рассматриваемых типов 
ошибок не обнаруживается, подобное исследование представля¬ 
ло бы незначительный интерес. Поэтому проведем сравнение 
машин нестандартной архитектуры, таких, как SWARD, SYM¬ 
BOL, учебная ПЛ-машина, и Burroughs 6500/6700, Система 38. 
Последняя система, имеющая двухуровневую архитектуру (см. 
гл. 4), рассматривается с точки зрения функционирования ин¬ 
терфейса уровня МІ, обеспечивающего на этапе выполнения 
реализацию контроля любого вида, который может быть со¬ 
здан средствами программного обеспечения этого уровня. Для 
получения более полного представления о перечисленных си¬ 
стемах, имеющих нетрадиционную архитектуру, сопоставим 
их с Системой 370 с традиционной архитектурой. Однако в ка¬ 
честве ее конкретного варианта будем использовать некоторую 
абстрактную модель, являющуюся комбинацией средств Систе¬ 
мы 370 и оптимизирующего компилятора языка ПЛ/1, разрабо¬ 
танного фирмой IBM. Такая модель Системы 370 обеспечивает 
на этапе выполнения реализацию любого контроля, задавае¬ 
мого средствами компилятора языка ПЛ/1. 

Сравнительные данные по указанным системам приведены 
в табл. 13.1. В графе «Количество типов ошибок, обнаруживае¬ 
мых полностью» этой таблицы указано количество типов оши¬ 
бок для каждой системы, которые обнаруживаются во всех слу¬ 
чаях. Если система обнаруживает лишь часть ошибок какого- 
либо типа или если она способна к выявлению этих ошибок 
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Таблица 13.1. Эффективность обнаружения ошибок различными системами 


Вычислительная система 

Количество 

бок, обнару- 

1 полностью 

Количество 

бок, обнару¬ 
живаемых 
частично 

Количество 

необнару- 

типов ошибок 

Абстрактная модель 

Системы 370 и компилятора ПЛ/1 

1 

3 

18 

В6500/6700 фирмы Burroughs 

6 

0 

16 

Система 38 

6 

4 

12 

SYMBOL 

10 

0 

12 

Учебная ПЛ-машина 

11 

2 

9 

Система SWARD 

21 

0 

1 


только по указанию программиста, то данные о таких типах 
ошибок помещаются в графу «Количество типов ошибок, обна¬ 
руживаемых частично». Если же данная система не способна 
выявлять ошибки некоторого типа, то сведения о соответству¬ 
ющих типах ошибок помещаются в графу «Количество типов 
необнаруживаемых ошибок». 

Если для простоты рассуждения принять, что все 22 типа 
ошибок имеют одинаковую значимость, то, согласно данным 
табл. 13.1, среди рассматриваемых систем имеются как очень 
надежные, так и весьма посредственные в этом отношении. Аб¬ 
страктная модель Системы 370 из 22 типов ошибок обнаружи¬ 
вает полностью ошибки только одного типа (деление на нуль). 
Машины с теговой памятью, памятью высокого уровня органи¬ 
зации, а также ориентированные на сугубо структурированный 
характер заданий (например, в виде совокупности процедур), 
такие, как SYMBOL, учебная ПЛ-машина и 'SWARD, обладают 
наилучшими характеристиками. Вычислительная система 
SWARD не обнаруживает ошибки только одного типа — выход 
за диапазон допустимых значений переменной. Так, например, 
при использовании в программе описания вида 

I: INTEGER range 1..12; 

система SWARD ни на этапе трансляции, ни на этапе выполне¬ 
ния не обеспечивает выявление ошибки при выходе значения 
переменной I за диапазон допустимых значений (от 1 до 12). 
Это не следует считать неким упрощением при разработке прин¬ 
ципов функционирования системы SWARD; было решено, что 
ошибки такого рода лучше всего обнаруживать, принимая во 
внимание стоимостные затраты и расход машинного времени 
посредством вставляемых в определенные места программы 
специальных команд тестирования, выполняемых компилято¬ 
ром. Так, машина SWARD располагает командой RANGE- 
CHECK, предназначенной для проведения этой проверки. 
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Если для некоторой системы не все 22 типа ошибок оказы¬ 
ваются в графе «Количество ошибок, обнаруживаемых полно¬ 
стью», то возможны два варианта решения проблемы выявле¬ 
ния необнаруживаемых ошибок. Первый вариант предполагает 
генерирование компилятором машинного кода контроля нали¬ 
чия подобных ошибок. 

Однако стоимость таких средств контроля колеблется от 
сравнительно умеренных значений (связанных с затратами па¬ 
мяти и машинного времени, в частности при контроле принад¬ 
лежности индексов элемента массива допустимому диапазону 
значений) до необычайно больших величин (например, при не¬ 
обходимости выявления переменных с неопределенными зна¬ 
чениями или неразрешенных адресных ссылок). Поэтому если 
средства контроля и реализуются на практике, то не в систе¬ 
мах массового промышленного производства, подобных ориенти¬ 
рованным на программирование на языке ПЛ/1, а только в 
учебных компиляторах. 

Другой вариант решения упомянутой проблемы сводится к 
игнорированию невыявленных ошибок, что влечет за собой от¬ 
каз от полной и строгой реализации требований спецификаций 
языка программирования, вследствие чего правильная работа 
системы становится зависимой от программиста. 

В заключение остановимся на двух моментах, имеющих от¬ 
ношение к компиляторам. Во-первых, несмотря на то что рас¬ 
смотренные ошибки в общем случае могут быть выявлены лишь 
на этапе выполнения программы (поскольку они определяются 
физическими связями, устанавливаемыми между значениями, 
адресами и признаками только к этому времени), некоторые 
признаки этих ошибок могут быть обнаружены и на этапе ком¬ 
пилирования. Если такая возможность имеется, то следует 
предусматривать соответствующие процедуры поиска. В част¬ 
ности, если компилятор может выявить очевидные ссылки на 
переменные с неопределенными значениями, использование зна¬ 
чений индекса, выходящих за установленные пределы, или не¬ 
соответствие фактических параметров формальным (что можно 
обнаружить, если обе процедуры компилируются совместно и 
атрибуты формальных и фактических параметров относятся к 
типу статических), имеет смысл процедуры поиска ошибок этих 
типов включить в структуру компилятора. Несмотря на это, 
по-прежнему остается желательной полная проверка машиной 
наличия всех возможных ошибок и на этапе выполнения. Это 
необходимо для выявления тех ошибок, которые не могут быть 
обнаружены во время компилирования, а также для того, что¬ 
бы не ставить работу всей системы в зависимость от правиль¬ 
ности и надежности работы всех входящих в систему компиля¬ 
торов. 
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Во-вторых, не следует полностью полагаться на решение 
всех возникающих проблем, которые приводят к ошибкам, сред¬ 
ствами описания, предоставляемыми языком программирова¬ 
ния. Например, средствами языка можно указать компилятору, 
что всем переменным, которым присвоение исходных значений 
программой не предусматривается, должно быть присвоено од¬ 
но и то же определенное значение (например, нулевое значение 
для числовых переменных, пробелы для строк символов). Хо¬ 
тя такие действия и устраняют возможность появления ошибок, 
носящих случайный (недетерминированный) характер, они по¬ 
хожи скорее на благие пожелания, чем на действия, гарантиру¬ 
ющие исключение соответствующих ошибок. Конечно, можно 
пойти по пути сокращения средств языка программирования: 
уменьшить количество типов данных, запретить независимое 
компилирование программных модулей, отказаться от средств 
манипуляции именами или указателями переменных. Однако та¬ 
кие меры могут привести только к значительной потере общно¬ 
сти принципов и средств программирования. 


ОБЗОР АРХИТЕКТУРЫ СИСТЕМЫ SWARD 

В данном разделе описываются основные характеристики ар¬ 
хитектуры системы SWARD и их связь с проблемой эффектив¬ 
ной разработки программного обеспечения. 


ТЕГОВАЯ ПАМЯТЬ 

В рассматриваемой архитектуре принят принцип организации 
памяти с помощью тегов. Такая память называется теговой, 
или памятью с самоопределяемыми данными. Благодаря исполь¬ 
зованию этого принципа машине становится понятно назначе¬ 
ние атрибутов операндов команд. Она легко обнаруживает в 
операциях несовместимые операнды и в процессе выполнения 
команд осуществляет автоматически требуемое преобразование 
данных. Данные каждого типа могут принимать значение, на¬ 
зываемое «неопределенным»; машина способна обнаруживать 
попытки использовать данные с неопределенными значениями. 

Элементы данных, снабженные тегами и называемые ячей¬ 
ками, имеют переменный размер (длину). Архитектурой систе¬ 
мы не предусмотрена фиксация размера слова данных, что по¬ 
зволяет машинным командам адресоваться к ячейкам как к опе¬ 
рандам. Благодаря этому модель данных, используемая архи¬ 
тектурой системы, хорошо согласуется с моделями языков про¬ 
граммирования. 
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ВЛОЖЕННЫЕ ТЕГИ 

Принцип теговой организации памяти получил в рассматривае¬ 
мой архитектуре дальнейшее развитие: одни теги могут быть 
вложены в другие. Это позволяет представлять данные более 
высокого уровня организации, такие, как массивы и структуры 
записи. Не программа, а машина берет на себя решение задачи 
адресации массива и автоматического контроля принадлежно¬ 
сти индексов допустимым диапазонам их значений. Вложенные 
теги используются также для определения базированных пере¬ 
менных в языке ПЛ/1 (переменных доступа в языке Ада) и 
данных, определяемых пользователем, т. е. так называемых 
абстрактных данных. 

Принцип вложения тегов удобно использовать для описания 
сложных данных. Например, описываемая пользователем четы¬ 
рехкомпонентная запись (т. е. запись из четырех полей) может 
включать в качестве первого компонента двумерный массив, 
каждый элемент которого представляет собой запись, и т. д. 


ПРИНЦИП ПОТЕНЦИАЛЬНОЙ АДРЕСАЦИИ 

В архитектуре системы SWARD применен принцип адресации 
и защиты памяти от несанкционированного доступа, называе¬ 
мый потенциальной адресацией. Согласно этому принципу, си¬ 
стема рассматривается как множество объектов, каждый из ко¬ 
торых при создании машиной получает присущее только этому 
объекту имя. Программы лишены возможности создавать или 
преобразовывать адреса. Каждое обращение к объекту, после 
того как он уничтожен, выявляется системой как ошибка. 

Потенциальные адреса и объекты используются для созда¬ 
ния моделей памяти высокого уровня (а не традиционных мо¬ 
делей низкого уровня) — это была одна из задач, стоявших пе¬ 
ред создателями архитектуры системы SWARD. На рис. 13.1 
приведен пример возможного состояния памяти системы. 
Сплошными стрелками показаны ссылки средствами потенци¬ 
альной адресации; штриховыми — внутренние связи между эле¬ 
ментами, поддерживаемые системой. Для данной архитектуры 
характерны пять типов объектов. Четыре из них (модуль, про¬ 
цесс-машина, порт и память данных) в явной форме создаются 
и используются программами, а один (запись активации) со¬ 
здается неявным образом в момент вызова модуля. 

Потенциальные адреса защищены от несанкционированного 
использования благодаря тому, что для представления каждого 
из них применяется одна теговая ячейка из 15 возможных ти¬ 
пов таких ячеек (данных). Как показано на рис. 13.1, потенци- 
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альные адреса используются также для обращения к устройств 
вам ввода-вывода последовательного действия, не имеющим 
своей памяти. 

ОДНОУРОВНЕВАЯ ПАМЯТЬ 

В данной архитектуре понятие виртуальной памяти обобщено 
настолько широко, что оказывается ненужным понятие вторич¬ 
ной (внешней) памяти. В частности, исключено понятие фай¬ 
ла; вместо него в программах используется понятие массива. 
Как следствие излишними оказались и понятия операций обме¬ 
на данными ввода-вывода со вторичной памятью. Адресация ко 
всем данным в системе выполняется единообразно, и все другие 
понятия архитектуры (например, использование тегов) относят¬ 
ся ко всем данным в равной степени. 

Архитектура не предоставляет программные средства для 
описания запросов на выделение памяти или для описания соот- 
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ветствующих процессов. Хотя выделение памяти имеет место, 
оно выполняется машиной без явного запроса со стороны про¬ 
граммы. Это происходит, например, в результате вызова оче¬ 
редного модуля, когда машина формирует запись активации 
для локальных переменных модуля. В этих условиях приходит¬ 
ся говорить не о возможностях программ запрашивать память, 
а о их возможностях запрашивать такие типы ячеек, как строки 
или массивы (динамическое выделение которых встроено в 
объект «память данных»). 

ОБЛАСТИ САНКЦИОНИРОВАННОГО ДОСТУПА 

Каждая программа или процедура представляется в системе 
объектом «модуль», который содержит последовательность ко¬ 
манд, получаемых в результате компилирования, и описание 



адресного пространства (указание группы ячеек памяти с тега¬ 
ми). Структура модуля показана на рис. 13.2. Команды некото¬ 
рого модуля могут адресоваться только к элементам собствен- 
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ного адресного пространства этого модуля, хотя через парамет¬ 
ры и потенциальные адреса эффективно реализуются косвенные 
ссылки и за пределы этого адресного пространства. Можно, та¬ 
ким образом, сказать, что данная архитектура способствует 
более полной реализации принципов модульного программиро¬ 
вания; ограничивает последствия возможных ошибок; защища¬ 
ет программы, включая системные, от несанкционированного 
доступа других программ, в том числе от несанкционированного 
доступа самих к себе. 

УПРАВЛЕНИЕ ПОДПРОГРАММАМИ 

Предусмотрено несколько команд, реализующих стандартные 
средства языков высокого уровня для вызова подпрограммы. 
Так, команда CALL сохраняет информацию о состоянии теку¬ 
щего модуля, создает запись активации для вызываемого моду¬ 
ля и присваивает ей исходное содержимое, переходит на работу 
с новым адресным пространством и начинает выполнение вы¬ 
званного модуля. При каждом вызове выполняется также про¬ 
верка соответствия типов фактических и формальных пара¬ 
метров. 

Как показано на рис. 13.2, адресное пространство модуля 
разделено на две части: статическую (ssd — static storage die) 
и динамическую (asd — automatic storage die). Ячейки статиче¬ 
ской части адресного пространства постоянно закреплены за мо¬ 
дулем. Во время каждого вызова точки входа модуля система 
создает объект «запись активации», куда копируются опреде¬ 
ления ячеек из динамической части адресного пространства. 
Когда команда обращается к ячейке динамической части адрес¬ 
ного пространства, система автоматически выполняет переад¬ 
ресацию в соответствующую ячейку текущей записи активации. 

Модуль может представлять собой процедуру с одной или 
несколькими точками входа или группу взаимосвязанных про¬ 
цедур (называемых пакетом в языке Ада). Какой из вариантов 
будет иметь место, зависит от заданного режима работы компи¬ 
лятора и действий программиста. 

ИЕРАРХИЧЕСКАЯ ОБРАБОТКА ОШИБОК 

В архитектуру системы включен специальный механизм обра¬ 
ботки ошибок, имеющий достаточно однородную структуру и 
ориентированный не столько на обслуживание системы в целом, 
сколько на обслуживание отдельных процессов. В каждом мо¬ 
дуле могут быть заданы точки входа для обработки ошибок и 
типы обрабатываемых ошибок. На рис. 13.3 изображено функ¬ 
ционирование механизма обработки ошибок. При обнаружении 
ошибки во время выполнения некоторого модуля машина в об- 
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ратном порядке просматривает список модулей, последователь¬ 
но вызывавшихся данным процессом. Поиск ведется до тех пор, 
пока не будет найден первый модуль, «выражающий желание» 
обработать ошибку данного типа. После нахождения такого мо¬ 
дуля машина обращает¬ 
ся к нему через его точку 
входа (аналогично вызо¬ 
ву подпрограммы), и пе¬ 
редает пять фактических 
параметров с информа¬ 
цией о типе ошибки и со¬ 
стоянии программы в 
этот момент времени. По¬ 
следующие действия оп¬ 
ределяются логикой про¬ 
граммы обработки оши¬ 
бок этого модуля. Пред¬ 
усмотрены команды для 
прекращения работы про¬ 
граммы обработки оши¬ 
бок и одна команда для 
явного задания условий 
возникновения ошибки. 

Таким образом, в об¬ 
щем случае объект типа 
«модуль» может состоять 
из локальных переменных, описателей данных, процедур функ¬ 
ционального назначения и процедуры обработки особых слу¬ 
чаев. 

ПРОЦЕСС-МАШИНА 

Одним из пяти типов объектов в архитектуре является объект 
«процесс-машина». Это абстрактное понятие, служащее для 
обозначения средств управления параллельными процессами. 
Создание и уничтожение процесс-машин означает формирова¬ 
ние и разрушение программами отдельных процессов. В соот¬ 
ветствии с общими принципами архитектуры это понятие озна¬ 
чает лишь средство, с помощью которого программы могут фор¬ 
мировать «линию своего поведения». Можно отметить, что это 
понятие не связано с другими понятиями архитектуры, в част¬ 
ности оно не имеет никакого отношения к адресации. 

МЕХАНИЗМ ПРИЕМО-ПЕРЕДАЧИ 

Для обеспечения связи между процессами в архитектуре систе¬ 
мы SWARD предусмотрены специальный абстрактный объект 
«порт» и две машинные команды SEND и RECEIVE. Команда 


Процесс 



SWARD. 
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SEND определяется почти так же, как и команда CALL, с тем 
отличием, что при выполнении команды CALL в точку входа 
модуля передаются управление и список фактических парамет¬ 
ров, а при реализации команды SEND через порт поступают 
фактические параметры. Иначе говоря, команда SEND служит 
для передачи данных, а не управления. При работе интерфейса 
приемо-передачи (SEND/RECEIVE), как и при вызове подпро¬ 
грамм, выполняется проверка типов данных. Как отмечалось 
выше, обращение к устройствам ввода-вывода без памяти осу¬ 
ществляется средствами потенциальной адресации; операции 
ввода-вывода выполняются посредством команд RECEIVE и 
SEND. 

КОМАНДЫ, ИНВАРИАНТНЫЕ 
К ТИПУ ОБРАБАТЫВАЕМЫХ ДАННЫХ 

Теговая организация памяти позволяет в рамках данной архи¬ 
тектуры ограничиваться небольшим набором однородных по 
структуре команд, инвариантных к типу обрабатываемых дан¬ 
ных. В частности, для сложения предусмотрена только одна ко¬ 
манда ADD, а для пересылки данных в памяти служит тоже 
одна команда MOVE. Семантика (содержательная часть) ко¬ 
манд определяется атрибутами их операндов. Например, коман¬ 
да MOVE может использоваться для перезаписи, целого числа 
в виде вещественного числа с плавающей точкой (имеет место 
автоматическое преобразование данных), для пересылки строки 
символов на место, занимаемое другой строкой символов, для 
записи скаляра во все элементы массива или для пересылки 
всех элементов одного массива в другой. 

МОЩНЫЙ НАБОР КОМАНД 

Кроме перечисленных выше команд система SWARD содержит 
команды адресации и перемещения частей строк в пределах 
строк, а также команду SEARCH для поиска в массиве элемен¬ 
та с заданным значением. Для синхронизации процессов пред¬ 
назначены команды GUARD и UNGUARD. Их можно использо¬ 
вать для предотвращения одновременного выполнения двумя 
или большим числом процесс-машин критических участков про¬ 
грамм. Эти команды разрабатывались для обеспечения возмож¬ 
ностей синхронизации при проектировании специальных про¬ 
грамм-мониторов. 

СРЕДСТВА КОСВЕННОЙ АДРЕСАЦИИ 

В рассматриваемой архитектуре принцип потенциальной адре¬ 
сации был расширен таким образом, чтобы предоставить воз¬ 
можность потенциальному адресу содержать ссылки на другие 
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потенциальные адреса. Благодаря этому, если программа содер¬ 
жит обращение к потенциальному адресу, машина интерпрети¬ 
рует это как ссылку на последний потенциальный адрес в звене 
таких адресов. Это свойство можно использовать для введения 
дополнительных уровней защиты данных, для контроля опера¬ 
ционной системой соблюдения санкционированного доступа к 
отдельным объектам или для динамического замещения объек¬ 
тов (например, модулей), к которым обращается программа во 
время выполнения. 

СРЕДСТВА ТРАССИРОВКИ ПРОГРАММ 

Архитектурой предусмотрены команды, подключающие средства 
трассировки переходов, изменивших последовательность выпол¬ 
нения команд, и переходов, не изменивших этой последователь¬ 
ности, а также трассировки вызовов подпрограмм отдельны¬ 
ми модулями. При обнаружении ситуаций, требующих трасси¬ 
ровки, система регистрирует их подобно состояниям ошибки и 
пускает в действие описанный выше механизм обработки 
ошибок. 


ДОПОЛНИТЕЛЬНЫЕ СРЕДСТВА ЗАЩИТЫ 
ОТ НЕСАНКЦИОНИРОВАННОГО ДОСТУПА 

В дополнение к таким средствам защиты, как упоминавшиеся 
выше потенциальная адресация, области санкционированного 
доступа и косвенная потенциальная адресация, данная архитек¬ 
тура располагает средством программного ограничения воз¬ 
можностей копирования потенциальных адресов, а также ко¬ 
мандой для назначения объектам новых имен. Можно заметить, 
что теговая структура памяти сама по себе является вспомога¬ 
тельным средством защиты доступа при работе с потенциаль¬ 
ными адресами: для получения доступа к некоторому объекту 
требуется не только его потенциальный адрес, но и знание его 
типа. 

ВИРТУАЛЬНЫЙ ХАРАКТЕР МАШИНЫ 

Некоторые атрибуты архитектуры системы SWARD, такие, как 
потенциальная адресация и описание всех процессов в системе 
в терминах абстрактных объектов, определяют такие ее черты, 
которые характерны для систем с виртуальной организацией 
памяти, хотя эта цель при разработке специально не пресле¬ 
довалась. В условиях такой виртуальной среды отдельные про¬ 
граммы могут не иметь явных связей с операционной системой, 
а выполнение программы в машине может поддерживаться од¬ 
новременно несколькими операционными системами. 
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ГЛАВА 14 

СИСТЕМА SWARD 

Рассмотрение системы SWARD, как и других систем, архитек¬ 
тура которых отлична от модели фон Неймана, целесообразно 
начать с принципов организации ее памяти. В этой главе обсуж¬ 
даются способы представления данных и адресации в системе 
SWARD и основные понятия, касающиеся организации памяти. 
В конце главы приводятся два примера, иллюстрирующие рабо¬ 
ту системы SWARD в режимах компилирования и выполнения. 

При описании архитектуры системы SWARD используются 
два термина: система и машина. Первый из них применяется 
для обозначения всей совокупности технических средств, вто¬ 
рой отождествляется с введенным выше абстрактным понятием 
«процесс-машина». Система представляется как набор «про¬ 
цесс-машин», количество которых меняется динамически на 
протяжении времени жизни системы. Вопрос о соответствии 
между процесс-машинами и реальными, аппаратно реализован¬ 
ными процессорами (один процессор используется одной про¬ 
цесс-машиной или один или несколько процессоров принадле¬ 
жат нескольким процесс-машинам) зависит от конкретной ре¬ 
ализации системы SWARD. 

ТИПЫ ДАННЫХ 

Прежде чем приступить к рассмотрению типов данных, исполь¬ 
зуемых в системе SWARD, необходимо определить несколько 
основных понятий, связанных с организацией памяти. За едини¬ 
цу исчисления размеров выделяемой памяти принимают то¬ 
кен — совокупность четырех смежных битов. Адресуемую еди¬ 
ницу памяти называют ячейкой. Последняя образуется из неко¬ 
торого (переменного) количества смежных токенов. В исходной 
программе каждой ячейке соответствует переменная или кон¬ 
станта (данные). Содержимое ячейки состоит из двух частей: 
тега, описывающего атрибуты содержащихся в ячейках данных, 
и самих данных. 
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В рассматриваемой архитектуре используются ячейки, а сле¬ 
довательно, и данные 15 типов, из них десять называются про¬ 
стыми, а пять — вложенными (с вложенными тегами). 

простые ячейки 

Структура ячеек для простых данных различных типов показа¬ 
на на рис. 14.1. Знак в форме треугольника используется для 
указания границы между полем, предназначенным для тега, 
и полем, представляемым для данных ячейки того или иного 
типа. Как и следовало ожидать, тег однозначно характеризует 
тип данных и сохраняется неизменным во время выполнения 
программы, т. е. не может быть изменен ею. В поле данных 
ячейки находится ее текущее содержимое. 

Ячейка «целое число» может содержать целое число в диапа¬ 
зоне от —8 388 607 до +8 388 607 либо признак неопределенно¬ 
сти. Это содержимое ячейки представляется в виде двоичного чис¬ 
ла и хранится в двоичном дополнительном коде. Содержимое дан¬ 
ной ячейки, равное 800 000 в шестнадцатеричной системе счис¬ 
ления, служит признаком неопределенности для обозначения 
неприсвоенного значения. Такое представление признака неоп¬ 
ределенности выбрано потому, что оно соответствует записи 
максимального отрицательного числа в двоичном дополнитель¬ 
ном коде. Следует отметить, что максимальное положительное 
число в качестве признака неопределенности не используется. 

Ячейка «целое число увеличенной разрядности» может со¬ 
держать целое число в диапазоне от —2 47 —1 до 2 47 —1, или при¬ 
мерно в диапазоне ±1,4 -ІО 14 . Признак неопределенности в этом 
случае равен 800 000 000000 (в шестнадцатеричной системе 
счисления). 

Ячейка «порядковое число» содержит числовую величину от 
0 до 254 в двоичной форме. Текущее содержимое ячейки явля¬ 
ется элементом упорядоченной числовой последовательности и 
может быть использовано как целое положительное число. Ве¬ 
личина 11111111 используется в качестве признака неопределен¬ 
ности. Величины 00000000 и 00000001 играют особую роль в 
логических командах — представляют значения логических пере¬ 
менных «истинно» и «ложно». Основным назначением этого типа 
данных является представление в таких языках, как Паскаль и 
Ада, так называемых нумерующих переменных (задаваемых пе¬ 
речислением их значений). 

Ячейка «десятичное число с фиксированной точкой» исполь¬ 
зуется для представления десятичных чисел фиксированного 
формата с точкой в указываемой позиции. Поле «размер» тега 
определяет количество цифр в числе. Поле «размер дробной ча¬ 
сти числа» задает для данного десятичного числа количество 
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Целое 



Рис. 14.1. Типы простых ячеек. 
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цифр, находящихся правее десятичной точки; эта величина мо¬ 
жет быть меньшей или равной общему количеству цифр числа. 
Следующие два поля предназначены для знака и величины чис¬ 
ла. В поле «знак» размещается знак числа. Величина 0000 
в этом поле символизирует положительный знак, —0001—от¬ 
рицательный знак числа, 1111—признак неопределенности. 
В последнем поле ячейки содержится абсолютное значение чис¬ 
ла, умноженное на 10 в степени, равной количеству дробных 
разрядов. Это число представлено в коде BCD (Binary-Coded 
Decimal — двоично-кодированный десятичный). 

В качестве примера отметим, что переменная с атрибутами 
FIXED DECIMAL (5,2), имеющая значение 7,9, в ячейке памя¬ 
ти представляется в виде: Е52000790. Если бы ее значение было 
неопределенным, в ячейке было бы записано число 
E52FXXXXX, где X символизирует неопределенное значение. 

Ячейка «десятичное число с плавающей точкой» .служит для 
представления числа в формате мантисса — порядок. Второе 
поле ячейки (см. рис. 14.1) служит для задания длины мантис¬ 
сы. Третье поле, как и в ячейке предыдущего типа, несет ин¬ 
формацию о знаке. Четвертое поле используется для знака по¬ 
рядка. В пятом поле содержится абсолютная величина поряд¬ 
ка в виде десятичного числа, значение которого не выходит за 
пределы диапазона 0—99. Последнее поле служит для записи 
десятичной мантиссы. Операции над десятичными числами с 
плавающей точкой всегда сопровождаются нормализацией ман¬ 
тиссы (путем ее сдвига с целью уничтожения ведущих нулей, 
если само число не является нулем). Порядок и мантисса пред¬ 
ставлены в коде BCD. 

Ячейки «десятичное число с фиксированной точкой» и «деся¬ 
тичное число с плавающей точкой» позволяют представлять 
нуль в двух вариантах: +0 и —0. Однако в рассматриваемой 
системе правильным представлением нуля считается только 
+ 0; —0 интерпретируется системой как данные неизвестного 
типа. 

Ячейка «поле символов» используется для записи группы 
символов фиксированной длины. Во втором поле этой ячейки 
задается число элементов в группе (от 1 до 4094 символов). 
Длина третьего поля (измеряемая в токенах) равна удвоенно¬ 
му значению содержимого второго поля. В третьем поле разме¬ 
щаются элементы текущего содержимого ячейки (символы). 
Содержимое ячейки, равное 11111111, используется в качестве 
признака неопределенности. 

Ячейка «поле токенов» предназначена для хранения элемен¬ 
тов, длина каждого из которых равна 4 бит. Во втором поле 
ячейки указывается количество токенов (эта величина не долж¬ 
на выходить за пределы диапазона значений от 1 до 1 048574). 



312 ГЛАВА 14 


Содержимое второго поля определяет длину третьего поля, 
в котором располагаются хранимые элементы (по одному на 
токен). Это единственный тип ячейки, для которой неопределен¬ 
ного значения не существует. 

Ячейка «строка символов» по структуре похожа на ячейку 
«поле символов», но может иметь переменную длину. Второе 
поле в теге этой ячейки предназначено для задания максималь¬ 
но возможного количества символов в строке (1—4094). 
В третьем поле указывается текущее количество символов в 
строке (0—4094), т. е. длина строки может динамически изме¬ 
няться. В четвертом поле размещается сама строка символов. 
Значение FFF в поле длины является признаком неопределен¬ 
ности для всей строки символов. 

Подобным же образом определяется ячейка еще одного ти¬ 
па— «строка токенов». Если в команде специальные указания 
отсутствуют, ячейка «строка символов» или «строка токенов» 
используется так же, как и ячейки «поле символов» и «поле то¬ 
кенов». При этом длина строки служит указателем размера 
поля символов. 

Последний тип ячеек для размещения простых данных — 
ячейка «указатель». В ней может храниться потенциальный ад¬ 
рес объекта (модуля, памяти данных, процесс-машины или пор¬ 
та) или элемента, принадлежащего указанному объекту (ячей¬ 
ки или ее части в модуле, записи активации, памяти данных 
или точки входа в модуль). Потенциальный адрес состоит из 
логического адреса и кода доступа. Логические адреса всегда 
присваиваются машиной и не могут быть изменены программой. 
Тем не менее программа может копировать содержимое одной 
ячейки «указатель» в другую ячейку «указатель». 

Код доступа в потенциальном адресе содержит информацию 
о правах, которыми располагает владелец потенциального ад¬ 
реса на доступ к адресуемому элементу. В архитектуре систе¬ 
мы SWARD не уточняется положение кода доступа в потенци¬ 
альном адресе, однако можно отметить, что он состоит из четы¬ 
рех двоичных разрядов следующего значения: 


разряда 


Вид доступа при единичном значении 
разряда 

1 

Чтение 

Чтение запрещено 

2 

Запись 

Запись запрещена 

3 

Уничтожение 

Уничтожение запрещено 

4 

Копирование 

Копирование запрещено 


Значение 1111 имеет смысл признака неопределенности, т. е. 
указатель содержит неопределенную величину. Вид доступа, 
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называемый «Копирование», означает возможность копировать 
потенциальный адрес. Если в потенциальном адресе некоторого 
указателя не задана возможность копирования, эту ячейку 
«указатель» нельзя использовать в качестве того операнда ко¬ 
манд MOVE или SEND, которым задается пересылаемая вели¬ 
чина. Отметим, что точное значение видов доступа «Чтение» 
или «Запись» зависит от типа адресата, на который ссылается 
указатель. 

Для изменения кода доступа имеется специальная команда, 
которая, однако, может только понизить степень доступа, вво¬ 
дя на него дополнительные ограничения. 

В архитектуре системы SWARD намеренно отсутствует оп¬ 
ределенная спецификация отдельных битов потенциального ад¬ 
реса. Однако для лучшего понимания архитектуры целесооб¬ 
разно рассмотреть эту спецификацию в конкретной реализации 
системы SWARD. Под потенциальный адрес отведено 84 бит: 
4 бит — для записи кода доступа; 32 бит — для имени объекта,, 
единственного в данной системе; 1 бит — для обозначения, яв¬ 
ляется ли этот потенциальный адрес обычным (непосредствен¬ 
ным) или косвенным, и две группы по 23 бит — для обращения,, 
если это необходимо, посредством потенциального адреса к эле¬ 
менту внутри объекта. Если допустить, что новые объекты в си¬ 
стеме генерируются в среднем каждые 100 мс (наиболее часто 
создаваемым объектам — записям активации — потенциальные 
адреса назначаются только при необходимости), то разнообра¬ 
зия имен, используемых для данной системы, хватит на 13 лет 
ее эксплуатации. Когда запас имен оказывается исчерпанным, 
система переходит к их повторному использованию, пропуская 
имена, которые еще заняты в работе. В результате возможна 
потенциальная адресация к 2 32 объектам, каждый из которых 
может занимать область памяти до 2 23 токен. 


ячейки с вложенными тегами 

Имеется пять разновидностей ячеек с вложенными тегами 
(рис. 14.2). Особенностью этих ячеек является то, что их теги 
содержат теги ячеек других типов. 

Ячейка «массив» служит для представления упорядоченного 
множества значений данных с одинаковыми атрибутами. Вто¬ 
рое поле ячейки этого типа предназначено для хранения дво¬ 
ичного представления общей длины тега; минимальное значение 
этой величины равно 16. В третьем поле находится размерность 
маосива (1—15), в четвертом — длина (в токенах) текущего со¬ 
держимого каждого элемента маосива. Эта длина может при¬ 
нимать любое значение в диапазоне от 1 до 65535. Следующие 
поля ячейки (количество которых равно размерности массива) 
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каждое длиной 6 токен определяют верхние границы количест¬ 
ва элементов массива по соответствующим компонентам его 
размерности. Результат умножения содержимого всех этих по¬ 
лей на содержимое четвертого поля равен общему количеству 




Рис. 14.2. Типы ячеек с вложенными тегами. 


токенов, занимаемых элементами массива. По умолчанию пред¬ 
полагается, что нижняя граница индекса по любому компонен¬ 
ту размерности массива равна 1. 

Предпоследнее поле ячейки предназначено для вложенного 
тега, описывающего элемент массива. Длина этого поля равна 
Длине соответствующего вложенного тега. Для элементов мас¬ 
сива допустимо использование ячеек следующих типов: ячейки 
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всех типов для простых данных, ячейки «запись», а также ячей¬ 
ки для простых данных и ячейки «запись», тип которых опреде¬ 
ляется пользователем. Если в качестве элементов массива 
используются записи стандартного типа или записи, тип кото¬ 
рых определяется пользователем, то компонентами таких запи¬ 
сей не могут быть массивы, т. е. архитектура не позволяет 
к использованию массивы массивов. 

Согласно общим принципам рассмотренной структуры ячей¬ 
ки «массив», ее последнее поле, предназначенное обычно для 
текущего содержимого ячейки, должно рассматриваться как 
местоположение элементов массива. Однако в архитектуре си¬ 
стемы SWARD назначение этого поля специально не определе¬ 
но. Это сделано для того, чтобы предоставить машине, выде¬ 
ляющей область памяти для элементов создаваемого массива, 
возможность поместить в это поле адрес указанной области, 
значение которого определяется конкретной реализацией си¬ 
стемы. 

При работе е массивами формирование необходимых индек¬ 
сов для элементов выполняется системой автоматически; опе¬ 
рандами многих команд могут быть как элементы массивов, 
так и массивы. Приведем пример расположения в ячейке «мас¬ 
сив» одномерного массива из 12 элементов, каждый из которых 
представляет собой строку из 10 символов: 

70131 000D00000C300AXXXXXX 1 ) 

Отметим, что два поля в этой ячейке нёсут избыточную ин¬ 
формацию по отношению к другим данным ячейки. Содержи¬ 
мым этих полей являются длина тега и длина элемента масси¬ 
ва. Обе эти величины можно определить, пользуясь содержи¬ 
мым других полей тега (например, информацией из вложенного 
тега). Эти поля были включены как дополнительные в процессе 
разработки архитектуры. Они позволяют упростить схемную 
реализацию и повысить скорость выполнения операций. 

Текущее содержимое и, возможно, даже атрибуты ячейки 
«параметр» определяются динамически во время вызова подт 
программы. Третье поле этой ячейки предназначено для вло¬ 
женного тега (рис. 14.2). Он задает атрибуты параметра и ис¬ 
пользуется машиной для проверки соответствия между факти¬ 
ческими и формальными параметрами. Допустимыми являются 
теги ячеек всех типов для простых данных, массива, записи, 
а также теги ячеек, тип которых определяется пользоватёлем. 
Длина поля вложенного тега равна длине самого вложенного 
тега. 


п Значение четвертого элемента ячейки в этом примере приведено в 
форме 000D, не учитывающей упоминавшегося выше правила расчета числа 
элементов в содержательной части ячейки типа «строка символов»; , с этим 
правилом'согласуется значение Ѳ0І7=23ю. — Прим, перев. ; ~ ’• лз 
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Если вложенный тег в ячейке «параметр» задан нулями, за¬ 
писанными в области размером 6 токен, или является тегом 
массива, вложенный тег которого представлен нулями, зани¬ 
мающими такую же область, то содержимое ячейки «параметр» 
называют параметром с динамически определяемым типом. Па¬ 
раметр такого типа динамически принимает атрибуты переда¬ 
ваемого фактического параметра. Если ячейка «параметр» 
«одержит вложенный тег с полем «размер» (например, в ячей¬ 
ках, предназначенных для десятичного числа с плавающей или 
фиксированной точкой, поля -или строки символов или токенов) 
и в нем содержится нулевое значение или если нулевым явля¬ 
ется значение в поле «размер» тега массива, вложенного в тег 
параметра, то содержимое ячейки «параметр» называют пара¬ 
метром с динамически определяемым размером. Содержимое 
поля «размер» параметра такого типа динамически устанавлива¬ 
ется равным значению передаваемого фактического параметра. 
Если тег, вложенный в тег параметра, является тегом массива, 
в одном или нескольких подполях верхних границ которого на¬ 
ходятся нули, содержимое ячейки «параметр» называют пара¬ 
метром с динамически определяемыми границами. Параметру 
такого типа по соответствующим компонентам размерности ди¬ 
намически назначаются верхние границы передаваемого мас¬ 
сива. Эти особенности передачи параметров рассматриваются в 
следующем разделе данной главы. 

Спецификация последнего поля в ячейке «параметр», так же 
как и последнего поля в ячейке «массив», данной архитектурой 
не предусмотрена. Это поле используется машиной SWARD в 
соответствии с ее конкретной реализацией для отыскания зна¬ 
чений параметра (соответствующего фактическому параметру) 
и для представления неопределенного значения. Независимо от 
того что подлежит размещению в последнем поле, первоначаль¬ 
но машина всегда записывает туда так называемые неопреде¬ 
ленные значения, т. е. признак того, что значение содержимого 
данного подполя еще не определено. 

Команды обращаются к ячейке «параметр» так, как если бы 
она была описана вложенным тегом. Разница заключается лишь 
в том, что при обращении к параметру машина определяет его 
значение не непосредственно, а косвенным образом, пользуясь 
информацией в последнем поле этой ячейки. 

Уточним смысл некоторых терминов, и в частности данных и 
ячеек. Когда речь идет о данных, например, таких типов, как 
целое число, поле символов, массив указателей целых чисел, то 
подразумевается ячейка одноименного типа, при обращении к 
которой можно получить указанные данные. Например, исполь¬ 
зование термина «целое число» предполагает обращение к ячей¬ 
ке любого типа, текущее содержимое которой имеет целочис- 
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денное значение, т. е. к ячейкам «целое число», «параметр цело¬ 
численного типа» (параметр с вложенным тегом целочислен¬ 
ного типа), элементу ячейки «массив целочисленного типа», 
к ячейке «косвенный доступ к данным целочисленного типа», 
ячейке целочисленных данных, тип которых определяется поль¬ 
зователем, к целочисленному компоненту ячейки «запись», 
и т. д. Термин «ячейка» употребляется для указания типа обла¬ 
сти памяти, предоставленной для размещения данных (текуще¬ 
го содержимого ячейки). Так появляются понятия ячейка «це¬ 
лое число», ячейка «параметр» и гг. п. Отсюда становится ясна 
разница между такими понятиями, как целое число и ячейка 
«целое число». 

В рассматриваемой архитектуре предполагается использо¬ 
вание ячейки «косвенный доступ к данным», содержащей дан¬ 
ные, к которым можно обращаться косвенно, т. е. посредством 
потенциального адреса. Такая ячейка используется, например, 
для размещения «базированной переменной» языка ПЛ/1. Для 
«переменной доступа» языка Ада необходимы ячейка «косвен¬ 
ный доступ к данным» и соответствующая ячейка «указатель». 

В третьем поле ячейки «косвенный доступ к данным» распо¬ 
ложен адрес ячейки «указатель», используемый для определе¬ 
ния местоположения данных, доступ к которым задается содер¬ 
жимым ячейки «косвенный доступ к данным». Адрес, о котором 
идет речь, является локальным адресом ячейки в пределах за¬ 
данного адресного пространства; в дальнейшем будет дано бо¬ 
лее полное определение и объяснение этого понятия. Пока 
лишь отметим, что данный адрес, задаваемый в ячейке «кос¬ 
венный доступ к данным», может использоваться для об¬ 
ращения только к ячейкам «указатель» или «указатель пара¬ 
метра». 

В последнем поле ячейки «косвенный доступ к данным» раз¬ 
мещается вложенный тег, определяющий атрибуты этой ячейки. 
Допустимы теги ячеек всех типов простых данных, ячеек «за¬ 
пись», «массив», а также ячеек, тип которых определяется 
пользователем. При выполнении команды, операндом которой 
является адрес ячейки «косвенный доступ к данным», регистри¬ 
руется ошибка, если вложенный тег указанной ячейки не сов¬ 
падает с тегом ячейки, доступ к которой осуществляется кос¬ 
венным образом посредством указателя. Подобно ячейке «пара¬ 
метр», ячейка «косвенный доступ к данным» может быть ячей¬ 
кой, тип, размер и границы числа элементов содержимого кото¬ 
рой определяются динамически. 

Как и при работе с ячейкой «параметр», программа опери¬ 
рует ячейкой «косвенный доступ к данным» таким образом, как 
будто бы доступ к данным является не косвенным, а прямым, 
т. е. как если бы тегом данной ячейки являлся ее вложенный 
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тег. Машина использует ячейку «указатель» для определения 
местоположения данных в памяти. 

Из описания команды ACTIVATE, приведенного в гл. 15 и в 
разделе данной главы, посвященном ячейкам с динамически 
определяемыми типом, размерами или границами, следует, что 
система проверяет соответствие между атрибутами ячейки, 
к которой установлен косвенный доступ, и атрибутами ячейки 
«косвенный доступ к данным» (т. е. информацией в ее вложен¬ 
ном теге), подобно тому как проверяется соответствие между 
атрибутами формальных и фактических параметров при пере¬ 
даче последних. Если соответствие нарушено, регистрируется 
ошибка «несовместимость операндов». 

Ячейка «запись» представляет собой совокупность ячеек, 
атрибуты которых могут отличаться друг от друга. Эти ячейки 
содержат не разрозненные данные, а компоненты одной записи. 
Теги всех отдельных компонентов содержатся в теге ячейки 
«запийь», а текущее содержимое ячеек (значения компонентов) 
образует текущее содержимое ячейки «запись». 

В теге ячейки «запись» содержатся длина тега, общая дли¬ 
на текущего содержимого ячейки и один или несколько дескрип¬ 
торов компонентов. Дескриптор каждого компонента состоит из 
смещения длиной 4 токен и тега переменной длины, характери¬ 
зующего соответствующий компонент. Смещение показывает на¬ 
чало соответствующего компонента при отсчете от первого то¬ 
кена текущего содержимого ячейки «запись». Вложенным тегом 
в данном случае может быть тег ячейки простых данных любого 
типа, ячеек «массив», «запись», а также ячеек, тип которых 
определяется пользователем. 

В качестве примера можно указать, что переменная CHIEF, 
определяемая как 

type PERSON is 
record 

SALARY : delta 0.01 range 0..99999.9; 

SEX : STRING (1..1); 

AGE : INTEGER; 

- end record; 

CHIEF ; PERSON; 

может быть представлена следующей ячейкой «запись»: 

801С001 00000E720008B0Q1000AFFXXXXXXXFF80Q000 


Предполагается, что все значения текущего содержимого не 
определены. Здесь идентификатор PERSON задан как ячейка 
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«запись», а идентификаторы SALARY, SEX и AGE определены 
не как отдельные ячейки, а как компоненты этой записи. После¬ 
довательно расшифровывая тег этой ячейки «запись», получаем 
следующую информацию. Длина тега ячейки равна 28 токен, 
а длина ее текущего содержимого —16 токен. (Числовые значе¬ 
ния в тегах представлены в двоичной системе счисления.) Те¬ 
кущее содержимое первого компонента, тип которого Е72, 
имеет нулевое смещение. Текущее содержимое следующего 
компонента типа В001 располагается со смещением 8, а текущее 
содержимое компонента типа F (целое число) располагается со 
смещением 10. 

Смещение текущего содержимого любого компонента де¬ 
скриптора должно равняться сумме смещения текущего содер¬ 
жимого предшествующего компонента и длины текущего содер¬ 
жимого предшествующего компонента, которая может быть из¬ 
влечена из его тега. Следовательно, текущее содержимое одно¬ 
го компонента даже частично не может перекрываться с теку¬ 
щим содержимым другого компонента. Хотя записи могут 
включать компоненты в виде записей, в свою очередь включаю¬ 
щих компоненты, смещение в дескрипторах любого компонента 
отсчитывается от начала текущего содержимого записи, внеш¬ 
ней по отношению ко всем остальным записям. Возможно, та¬ 
кое решение не является изящным, но оно способствует эффек¬ 
тивной реализации системы. 

Ячейкой, тип которой определяет или, выражаясь точнее, 
доопределяет пользователь, может быть ячейка «массив» или 
ячейка «запись» с префиксом (приставкой) в виде атрибутов, 
задаваемых пользователем, например, на этапе компилирова¬ 
ния. Машина оперирует такой ячейкой, как ячейкой, включен¬ 
ной в описание ячейки другого типа. Разница между -непосред¬ 
ственным обращением к некоторой ячейке и обращением к ячей¬ 
ке согласно типу, определяемому пользователем, заключается 
в том, что в последнем случае в ряде ситуаций машина может 
использовать для проверки типа информацию, включенную в 
качестве префикса. В поле «тег пользователя» может быть по¬ 
мещена произвольная информация, представляющая определен¬ 
ные пользователем атрибуты. Например, ячейка с данными 
10090001 F000008 является ячейкой «целое число», текущее со¬ 
держимое которой равно +8, а тег пользователя равен 0001. 

При использовании ячейки, тип которой определяется поль¬ 
зователем, в качестве операнда команды машина в большинст¬ 
ве случаев игнорирует префикс и оперирует этой ячейкой как 
ее вложенной частью. Специфика ячейки, тип которой опреде¬ 
ляется пользователем, проявляется в следующих случаях: когда 
тег пользователя оказывается вложенным тегом ячейки «пара¬ 
метр»; когда ячейка, тип которой определяется пользователем, 



передается в порт или принимается из него; если операндом 
команды является ячейка «косвенный доступ к данным», тип 
которой определяется пользователем. Во всех указанных слу¬ 
чаях машина выполняет проверку типа с использованием ин¬ 
формации в префиксе, добавляемом пользователем. 

Итак, если учесть разнообразие возможного задания вло¬ 
женных тегов, уточнение типа ячейки посредством префикса, 
добавляемого к ячейке пользователем, атрибуты динамически 
определяемых типов, размеров и границ, то общее число разно¬ 
образных определений ячеек оказывается весьма большим. 
Примеры обращения к ячейкам многих перечисленных типов 
приведены в последующих разделах данной главы. 

Выше рассмотрено 15 типов ячеек из возможного общего ко¬ 
личества типов, равного 16. На основании этого можно было 
ошибочно заключить, что при необходимости расширения 
средств архитектуры допустимо введение еще только одного до¬ 
полнительного типа. В действительности же код 0000 в первых 
четырех двоичных разрядах ячейки используется как признак 
расширения типа, в соответствии с которым тип ячейки иденти¬ 
фицируется следующими четырьмя двоичными разрядами. Это 
позволяет иметь в системе практически неограниченное число 
различных типов ячеек. Ниже рассматриваются особенности ар¬ 
хитектуры, предоставляющие возможность оперировать расши¬ 
ренным набором команд. Используя признаки расширения типа, 
команды из расширенного набора могут формировать ячейки 
новых типов. Например, в условиях ориентированного на 
ФОРТРАН расширенного набора команд ячейка, начинающая¬ 
ся кодом 00001111, может обозначать комплексное число в язы¬ 
ке ФОРТРАН (число с вещественной и мнимой частями). Ана¬ 
логичного результата можно добиться, снабжая ячейку «за¬ 
пись» с двухкомпонентным текущим содержимым, префиксом 
(тегом пользователя), т. е. доопределяя тип этой ячейки. 

Ниже рассматриваются еще несколько типов ячеек для дан¬ 
ных, которые включены в архитектуру в дополнение к описан¬ 
ным выше 15 типам ячеек. 


КОСВЕННЫЕ ПОТЕНЦИАЛЬНЫЕ АДРЕСА 

Косвенная адресация в рассматриваемой архитектуре основана 
на применении косвенных потенциальных адресов. Формально 
косвенный потенциальный адрес (ссылается на другой потенци¬ 
альный адрес, не являющийся косвенным. Машиной это воспри¬ 
нимается как указание на элемент памяти, адресуемый вторым 
из этих потенциальных адресов. Любая ссылка средствами кос¬ 
венной потенциальной адресации через некоторый потенциаль¬ 
ный адреіс к указываемому им элементу памяти эквивалентна 
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непосредственной ссылке к элементу памяти с помощью этого 
потенциального адреса. Разница состоит лишь в том, что при 
использовании косвенной адресации применяется код доступа 
из косвенного потенциального адреса. Любая операция (пере¬ 
сылка, сравнение и т. п.) с указателем, содержащим косвенный 
потенциальный адрес, приводит к тому же результату, что и 
операция с указателем, содержащим обычный (некосвенный) 
потенциальный адрес. Например, если указатель А содержит 
косвенный потенциальный адрес другого указателя В, любое ис¬ 
пользование в командах указателя А для обращения к памяти: 
эквивалентно использованию указателя В, за исключением 
того, что в операции участвует код доступа указателя А, а не В. 
Любые операции, выполняемые непосредственно с указате¬ 
лем А, ссылаются только на него, а не на указатель В. Косвен¬ 
ная адресация используется при выполнении так называемого» 
разрешения потенциальных адресных ссылок, например при об¬ 
ращении к ячейке «косвенный доступ к данным» и выполнении 
команды CALL или команды SEND, пересылающей данные 
в порт. 

Косвенную потенциальную адресацию можно использовать- 
в различных целях. В частности, с ее помощью можно управ¬ 
лять санкционированным доступом. Например, было бы жела¬ 
тельно, чтобы программа А предоставила программе В доступ 
к некоторым данным, сохранив за собой возможность лишить 
программу В этого права на доступ в любой момент времени* 
Это достигается предоставлением программе В косвенного по¬ 
тенциального адреса указателя, содержащего непосредственный 
(прямой) потенциальный адрес указанных данных. Програм¬ 
ма А может в любой момент изменить содержимое указателя 
и тем самым лишить программу В доступа к этим данным* 
Косвенную адресацию можно использовать также для динами¬ 
ческой смены объектов или модулей без специального переоп¬ 
ределения связей этих объектов или программ. В частности, 
если модуль X вызывает модуль Y посредством косвенного по¬ 
тенциального адреса, можно выполнить замену Y на новый мо¬ 
дуль изменением того (прямого) потенциального адреса, кото¬ 
рый непосредственно указывает на вызываемый модуль. При 
этом не требуется никаких изменений в модуле X. Еще одна 
возможность применения косвенных адресов связана с органи¬ 
зацией управления доступом к объектам, что характерно, на¬ 
пример, для операционных систем. В частности, функцию опера¬ 
ционной системы, состоящую в управлении использованием 
объектов как ресурсов с возможностями запроса монопольного 
или совместного управления, лучше всего организовать на ос¬ 
нове обращения программ к косвенным, а не непосредственным 
потенциальным адресам. 

21—283 
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ячейки с динамически определяемыми 

ТИПОМ, РАЗМЕРОМ ИЛИ ГРАНИЦАМИ 

Выше отмечалось, что ячейки «параметр» и «косвенный доступ 
к данным» допускают динамическое задание типа, размера и 
границ их текущего содержимого. Эти свойства позволяют фор¬ 
мировать программы, в значительной степени не зависящие от 
атрибутов обрабатываемых ими данных. 

Ячейки «параметр» с вложенными ячейками «поле симво¬ 
лов», «строка символов», «поле токенов», «строка токенов», 
«десятичное число с фиксированной точкой» или «десятичное 
число с плавающей точкой» допускают динамическое измене¬ 
ние размера их текущего содержимого, если во вложенном 
теге ячейки «параметр» в поле «размер»записать нули. Напри¬ 
мер, код 6008В003ХХХХХХХ представляет ячейку «параметр» 
с вложенной ячейкой «поле символов», размер текущего содер¬ 
жимого которой равен 3; что же касается кода 
6008В000ХХХХХХХ, то он представляет подобную ячейку «па¬ 
раметр», допускающую динамическое задание указанного раз¬ 
мера. Аналогичным образом ячейки «параметр» с вложенными 
ячейками «массив» (которые в свою очередь являются совокуп¬ 
ностью полей и строк символов, десятичных чисел с фиксиро¬ 
ванной и плавающёй точками) становятся ячейками с динами¬ 
чески изменяемым размером текущего содержимого, если при¬ 
своить нулевое значение содержимому вложенного тега мас¬ 
сива. 

Описываемый механизм динамического определения харак¬ 
теристик данных схож с использованием в языке ПЛ/1 для 
подобных целей символа «звезда», но более удобен для разра¬ 
ботки программ. Приведем примеры параметров с динамически 
определяемым размером и соответствующие решения средства¬ 
ми языка ПЛ/1: 


Q. PROCEDURE^, В); 

6007Е0ХХХХХХХХ DECLARE FIXED DECIMALS); 

601770131ХХХХОООООЭВОООХХХХХХ DECLARE B(9) CHARACTER 

О; 

Поле длины элемента во вложенном теге массива в ячейке 
«параметр» или «косвенный доступ к данным» не используется 
и может заполняться любым содержимым. Как обычно, символ 
X обозначает произвольное значение. 

Если формальный параметр процедуры наделен свойством 
динамического определения размера, он автоматически получа¬ 
ет значение атрибута «размер» соответствующего фактического 
параметра процедуры. Ниже в определении команды ACTIVATE 
перечислены правила соответствия типов формальных и фак¬ 
тических параметров. 
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Динамическое задание размеров текущего содержимого» 
возможно для полей и строк символов, целых чисел, чисел с 
фиксированной или плавающей точкой, а также для массивов, 
если доступ к ним осуществляется косвенно, т. е. посредством 
ячейки «косвенный доступ к данным». Динамическое задание- 
размеров для ячейки «косвенный доступ к данным» осуществля¬ 
ется подобно тому, как это делается для ячейки «параметр». 
Обратимся к следующим примерам: 

500CYYYY3000 DECLARE A CHARf) VARYING 

BASED (Р); 

501 AYYYY70T21 ХХХХ000009Е0Х DECLARE В(9) FIXEQ DECIMAL 
(*) BASED (P); 

В этих примерах YYYY обозначает адрес ячейки указате¬ 
ля Р. Запись на языке ПЛ/1 носит условный характер, так как 
правила этого языка не позволяют откладывать взаимную при¬ 
вязку переменных на более поздний этап формирования рабо¬ 
чей программы. 

При каждом обращении к ячейке «косвенный доступ к дан¬ 
ным», используемой в режиме динамического определения раз¬ 
мера текущего содержимого ячейки косвенно адресуемых дан¬ 
ных, первая из упомянутых ячеек получает значение размера 
содержимого второй ячейки. Согласование между этими пара¬ 
метрами двух ячеек аналогично тому, которое осуществляется 
между формальными и фактическими параметрами процедуры. 

Динамическое определение размеров того или иного текуще¬ 
го содержимого не может быть использовано применительно к 
ячейке «запись», но допускается при работе с ячейкой «пара¬ 
метр» или «косвенный доступ к данным», тип которой опреде¬ 
ляется пользователем. 

Режим динамического определения границ числа элементов' 
массива задается записью нулей в одном или нескольких полях 
верхних границ вложенного тега этого массива. Приведем приг- 
меры: 


Q: PROCEDURE^, В); 

601С70182ХХХХ000000000002Е42ХХХХХХХ DECLARE А(*,2) 

FIXED DEC (4,2); 

601770131ХХХХООООООВОООХХХХХХХ DECLARE В(*) 

CHAR(*); 

Как следует из второго примера, режимы динамического 
определения границ и размера реализуются независимо друг от 
друга, т. е. массив параметров может обладать обеими этими 


21' 
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возможностями. Если последний используется в режиме дина¬ 
мического определения границ, то для каждого компонента 
размерности, имеющего нулевое содержимое поля верхней гра¬ 
ницы, автоматически назначаются соответствующие верхние 
границы массива фактических параметров. 

Любая ячейка «косвенный доступ к данным» может исполь¬ 
зоваться также и в режиме динамического определения границ 
косвенно адресуемого массива. Это достигается способом, ана¬ 
логичным описанному выше. 

501 BYYYY701 31ХХХХООООООВООО DECLARE А(*) CHAR(') 

BASED (Р); 

В данном примере, как и в предыдущем, ячейка обладает 
свойствами динамического определения как размера, так и 
границ. 

При каждом обращении к ячейке «косвенный доступ к дан¬ 
ным», используемой в режиме динамического определения гра¬ 
ниц косвенно адресуемого массива, она получает значения гра¬ 
ниц этого массива для всех компонентов, представленных в ней 
нулевыми значениями. Режим диамического определения гра¬ 
ниц компонентов массива может использоваться также для мас¬ 
сивов внутри записей и массивов, тип которых задается пользо¬ 
вателем. 

Для использования ячейки «параметр» в режиме динамиче¬ 
ского определения типа данных 6 токен вложенного тега этой 
ячейки должны иметь нулевые значения. Для задания такого 
же режима для параметра в виде массива указанное количест¬ 
во нулей должно быть помещено во вложенный тег (описываю¬ 
щий элемент массива) внутри вложенного тега массива. 

Q: PROCEDURE (А,В); 

600А000000ХХХХХХХ DECLARE A D-TYPED; 

601970151ХХХХ000000000000ХХХХХХХ DECLARE В(*) D-TYPED; 


В первом из приведенных здесь примеров в режиме динами¬ 
ческого определения типа в качестве параметра используется 
скалярная величина. В этом случае он автоматически получает 
все атрибуты соответствующего фактического параметра. По¬ 
следний, однако, не может быть записью, массивом или элемен¬ 
том, тип которого определяется пользователем. Если в режиме 
динамического определения типа в качестве параметра исполь¬ 
зуется массив, он автоматически получает все атрибуты элемен¬ 
тов соответствующего массива фактических параметров. 
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Второй пример показывает задание режима динамического 
определения не только типа элементов массива, но и границ их 
компонентов. 

Режим динамического определения типа для ячейки «косвен¬ 
ный доступ к данным» может быть задан помещением нулей в 
область из 6 токен вложенного тега. С целью задания такого 
же режима для подобной ячейки, обеспечивающей доступ к мас¬ 
сиву, указанное количество нулей необходимо поместить во 
вложенный тег вложенного тега массива. Подобный режим мо¬ 
жет быть задан для любой ячейки «косвенный доступ к дан¬ 
ным», адресующейся к массиву: 

SOOEYYYYOOOOOO DECLARE A D-TYPED 

BASED (Р); 

501 DYYYY701 51 ХХХХ000000000000 DECLARE В(*) D-TYPED 

BASED (Р); 


Во втором примере для ячейки «косвенный доступ к дан¬ 
ным» заданы одновременно как режим динамического опреде¬ 
ления типа, так и режим динамического определения границ. 

Если в режиме динамического определения типа данных ис¬ 
пользуется ячейка «косвенный доступ к данным», адресующая¬ 
ся к данным скалярного типа, как в первом примере, то при 
каждом обращении к ячейке с этими данными ячейка «косвен¬ 
ный доступ к данным» получает все атрибуты косвенно адресуе¬ 
мой ячейки. В качестве последней нельзя использовать ячейки 
«запись», «массив», а также ячейки, тип которых определяется 
пользователем. Если ячейка «косвенный доступ к данным» и ис¬ 
пользуется в режиме динамического определения типа данных, 
представляющих собой массив, то при каждом обращении к ней 
она получает все атрибуты элементов такого косвенно адресуе¬ 
мого массива. 

Неправильно было бы считать, что возможности динамиче¬ 
ского определения типов и размеров данных, а также границ 
массивов делают архитектуру SWARD менее надежной и защи¬ 
щенной от несанкционированного доступа. Использование этих 
возможностей в сочетании с теговой памятью и системой ко¬ 
манд, инвариантных к типу обрабатываемых данных, позволя¬ 
ет создавать программы, в значительной степени независимые 
от обрабатываемых данных. При несовпадении типов данных 
(например, при попытках выполнить арифметические операции 
над полями символов) ошибка будет обнаружена и при исполь¬ 
зовании режима динамического определения соответствующих 
характеристик ячеек. Возможно только, что она будет обнару¬ 
жена несколько позднее, чем если бы этот режим не использо- 
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вался. Например, если формальный параметр определен как 
одномерный массив из 10 элементов типа «поле символов», раз¬ 
мер каждого из которых равен 6, то при вызове процедуры или 
модуля система обнаружит ошибку, если соответствующий 
фактический параметр не обладает такими же характеристи¬ 
ками. Однако, если формальный параметр используется в ре¬ 
жиме динамического определения типа и границ, проверка фор¬ 
мального параметра будет выполняться только на одномерность 
массива, передаваемую в качестве фактического параметра. 
Если при последующем выполнении процедуры встретится ко¬ 
манда с операндами, предполагающими другие характеристи¬ 
ки массива (например, с попытками обращения к несущест¬ 
вующему элементу, обращения о элементами как с числами, ког¬ 
да в действительности они таковыми не являются, или обраще¬ 
ния к несуществующим частям элемента массива, являющегося 
полем или строкой), то регистрируется ошибка. 

ОБЪЕКТЫ СИСТЕМЫ 

В системе различаются объекты пяти типов: модули, записи 
активации, память данных, процесс-машины и порты. 

МОДУЛЬ 

Главным объектом в процесс-машинах является модуль. Мо¬ 
дуль состоит из последовательности машинных команд и адрес¬ 
ного пространства данных, которыми оперируют машинные 
команды. 

Модуль в системе SWARD соответствует таким понятиям в 
языках программирования, как пакет в языке Ада, внешняя 
процедура и функция в языке ПЛ/1, подпрограмма в языке 
КОБОЛ и подпрограмма SUBROUTINE в языке ФОРТРАН. 
Модуль создается с помощью команды CREATE-MODULE. Эта 
команда обращается к внешней форме модуля (рис. 14.3), 
представленной в виде строки токенов, и на ее основе создает 
объект «модуль». Следовательно, в архитектуре SWARD струк¬ 
тура модуля не является раз и навсегда определенной: она за¬ 
дается описанием упомянутой выше так называемой внешней 
формы модуля (сокращенно внешний модуль). Модуль может 
быть разрушен командой DESTROY или в момент уничтожения 
процесс-машины; последняя возможность может быть запроше¬ 
на при необходимости. 

Внешний модуль выступает в качестве основного интерфейса 
с системой, поскольку представляет собой выходные данные 
компилятора. Согласно рис. 14.3, внешний модуль состоит из 
трех частей: .заголовка фиксированной длины и имеющих пере¬ 
менную длину адресного пространства и пространства команд. 
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В заголовке модуля указываются некоторые атрибуты мо¬ 
дуля и определяются составные элементы других частей моду¬ 
ля. Каждое из первых четырех полей заголовка состоит из 
5 токен, содержащих внутренние указатели на начало отдель¬ 
ных основных областей в модуле. Кроме того, эти указатели 
используются системой для расчета последних информационных 
разрядов предыдущих областей. Поэтому упомянутые основные 
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Рис. 14.3. Структура внешнего модуля. 


области должны быть смежными. Если некоторая область от¬ 
сутствует, предназначенный ей указатель устанавливается на 
начало следующей области. Например, если отсутствует дина* 
мическая часть адресного пространства, указатель этой области 
и указатель статической части адресного пространства имеют 
одно и то же значение. 

Два поля, CAS и IAS, длиной 1 токен используются для 
задания длины адресов ячеек и команд в командах данного 
модуля. Каждое поле может содержать двоичную величину, 
указывающую количество токенов в адресах этого модуля. По¬ 
нятия «адрес ячейки» и «адрес команды» поясняются ниже в 
разделе, описывающем форматы команд. (Отметим, что адреса 
ячеек, содержащиеся в ячейках «косвенный доступ к данным», 
имеют фиксированную длину, равную 4 токен.) 

Поскольку адресное пространство модуля ограничено только 
теми ячейками, которые определены в этом модуле, целесооб¬ 
разно ограничивать длину используемых адресов наименьшим 
достаточным значением. Так, вместо того чтобы в командах 
задавать для адресов поля фиксированной длины, оказывается 
более предпочтительным подбирать размеры этих полей для 
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каждого модуля. Необходимо только, чтобы длина адресов для 
обращения к ячейкам была достаточной для адресации ко всем 
имеющимся ячейкам в модуле, т. е. для адресного пространства 
модуля. Аналогичным образом необходимо, чтобы длина адре¬ 
сов для обращения к командам была достаточной для адреса¬ 
ции ко всем имеющимся командам области команд модуля. 
В соответствии с этим при работе с модулями, в которых имеется 
мало ячеек небольшого размера, можно ограничиться коротки¬ 
ми адресами ячеек; при работе же с модулями более крупных 
размеров, содержащими большее число ячеек, потребуются бо¬ 
лее длинные адреса. 

Архитектура системы SWARD принципиально допускает вы¬ 
бор значений CAS и IAS. Однако в реализованном варианте сис¬ 
темы значения CAS и IAS приняты постоянными и равными трем. 

Следующее поле заголовка модуля SIS — идентификатор* 
конкретного расширенного множества команд — состоит из 
1 токен и определяет исходный язык программирования моду¬ 
ля. Включение этого поля в состав заголовка модуля объясня¬ 
ется стремлением расширить базовое множество команд допол¬ 
нительными командами, отражающими специфику языков про¬ 
граммирования. Например, если в поле SIS находится 0, код 
операции 0087 может оказаться недопустимым. Если значение 
содержимого SIS равно 1, код 0087 может соответствовать ко¬ 
манде PICTURE — редактирование данных с шаблоном — при 
использовании языка ПЛ/1. Если содержимое указанного поля 
равно 2, тот же код 0087 может обозначать одну из команд об¬ 
ращения к базе данных. Приведенный пример указывает и на; 
другое достоинство системы: оказывается возможным освобо¬ 
дить разработчиков отдельных систем (например, разработчи¬ 
ков транслятора КОБОЛа) от необходимости принимать во 
внимание информацию о командах, связанных с операционной 
системой. Команды, не входящие в определенные множества 
программ и не используемые отдельными программистами, ока¬ 
зываются как бы скрытыми от них, что представляет собой 
определенное удобство. 

Наличие подобного поля расширения набора команд или 
средств языка программирования позволяет динамически изме¬ 
нять часть набора команд системы, предоставляя системным 
программистам возможность видоизменять набор команд в со¬ 
ответствии с меняющимися требованиями таким образом, что¬ 
бы это оставалось «незамеченным» для уже разработанных и 
действующих программ. В существующем варианте реализован¬ 
ной системы SWARD возможность включения дополнительных 
множеств команд не используется. 

Последнее поле заголовка модуля имеет длину 6 токен и со¬ 
держит коды ошибок (обнаруживаемых во время работы ма- 
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шины), которые подлежат обработке по заявке данного модуля. 
Назначение этого поля рассматривается в одном из следующих 
разделов, посвященном обработке ошибок. 

Второй частью внешнего модуля является его адресное про¬ 
странство. Оно содержит группы ячеек, определяющих данные, 
к которым может обращаться данный модуль. Порядковый но¬ 
мер первого токена любой ячейки адресного пространства опре¬ 
деляется как адрес ячейки. Так, адрес первой ячейки равен ], 
адрес второй ячейки на единицу больше длины первой ячейки 
и т. д. 

Хотя программа воспринимает адресное пространство как 
единое целое, в нем можно выделить две части. Они использу¬ 
ются системой для распределения областей памяти и управле¬ 
ния доступом к ним. 

В динамической части адресного пространства расположены 
ячейки, играющие роль динамически распределяемой памяти 
при вызове модуля. Когда такой вызов осуществляется, система 
формирует запись активации и копирует в нее динамическую 
часть адресного пространства. Если команда программы обра¬ 
щается к ячейке динамической памяти адресного пространства, 
система автоматически преобразует адрес этой ячейки в адрес 
ее копии в записи активации модуля. 

Машина строго поразрядно копирует динамическую часть 
адресного пространства в запись активации. В результате ком¬ 
пилятор может обеспечить динамической переменной 1 ) возмож¬ 
ность получения начального значения путем записи требуемого 
значения в ячейку этой переменной в динамической части адрес¬ 
ного пространства. Если динамическая или какая-либо другая 
переменная не имеет начального значения, то компилятор по¬ 
мещает в ячейку признак неопределенности (неопределенное 
значение). Исключением из этого общего правила являются 
ячейки «указатель». В целях гарантии защиты от несанкциони¬ 
рованного доступа установка начальных значений ячеек «указа¬ 
тель» при создании объекта выполняется помещением в них 
признака неопределенности. В динамической части адресного 
пространства могут присутствовать ячейки всех типов. Если в 
динамической части адресного пространства размещается ячей¬ 
ка «массив», то область памяти для хранения всех элементов 
массива выделяется в записи активации. Исходные значения 
этих элементов задаются как неопределенные. Ячейки «пара¬ 
метр» должны располагаться только в этой части адресного 
пространства. При создании модуля исходные значения этих 
ячеек также назначаются неопределенными. 

>> Динамическими называются переменные, выделение и освобождение 
памяти под которые осуществляется системой соответственно при каждом 
входе и выходе из блока программы. — Прим, перев. 



Статическая часть адресного пространства содержит ячейки 
переменных, для которых память выделяется только один раз 
перед выполнением (т. е. при выполнении команды CREATE- 
MODULE). Если такой переменной, называемой статической, 
должно быть присвоено исходное значение, его следует помес¬ 
тить в ячейку этой переменной в статической части адресного 
пространства. В противном случае в ячейке должен находиться 
признак неопределенности (этот признак устанавливается си¬ 
стемой в качестве начального значения для всех ячеек «указа¬ 
тель»). В статической части адресного пространства могут 
встречаться вое типы ячеек, за исключением ячеек «параметр». 
Начальные значения элементов массивов устанавливаются не¬ 
определенными. 

Последняя часть внешнего модуля — область команд, содер¬ 
жащая последовательность машинных команд. Большинство 
машинных команд имеет переменную длину. Порядковый номер 
первого токена команды в области команд считается адресом 
команды. Адрес первой команды равен 1, адрес второй команды 
на единицу больше длины первой команды и т. д. 

ЗАПИСЬ АКТИВАЦИИ 

Объект «запись активации» содержит пространство для ячеек, 
расположенных в динамической части адресного пространства 
модуля. Этот объект создается при активации модуля с по¬ 
мощью команды CALL и уничтожается, когда данный модуль 
возвращает управление вызывающему модулю или когда унич¬ 
тожается соответствующая процесс-машина. В программе не 
предусмотрено средств для обращения к записи активации 
(адресация к ней выполняется неявно, через динамическую 
часть адресного пространства), поэтому описание архитектуры 
системы SWARD не содержит более подробных сведений о за¬ 
писи активации. 


память ДАННЫХ 

Объект «память данных» создается программой, согласно алго¬ 
ритму работы которой необходимо динамически выделять па¬ 
мять для ячейки «косвенный доступ к данным». Другими сло¬ 
вами, выделяется память на случай динамического создания 
ячейки системой. Эти действия выполняются по команде 
ALLOCATE. Память закрепляется за модулем временно до тех 
пор, пока не будет выдана команда DESTROY или в случае, 
если указан специальный необязательный параметр в команде 
ALLOCATE— до уничтожения процесс-машины. Так как к объек¬ 
ту «память данных» программа обращается не прямо, а посред- 
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ством ячейки «косвенный доступ к данным», то в документации 
рассматриваемой архитектуры отсутствует более подробное 
описание этого объекта. 

ПРОЦЕСС-МАШИНА 

Спецификой объекта, именуемого процесс-машиной, является 
тот факт, что он параллельно с другими процесс-машинами 
выполняет один или несколько модулей архитектуры системы 
SWARD. Выполнение команд модулей процеос-машиной назы¬ 
вается процессом. Процесіс-машина создается в результате вы¬ 
полнения другой процесс-машиной команды CREATE- 
PROCESS-MACHINE. Уничтожается процесс-машина одним из 
следующих способов: командой DESTROY; по команде воз¬ 
врата в инициированный процесс; при появлении ошибки та¬ 
кого типа, для которого данный процесс не располагает соот¬ 
ветствующими средствами обработки ошибок, или при уничто¬ 
жении процесс-машины, которая выполняла процесс, породив¬ 
ший данную процесс-машину, если в команде CREATE- 
PROCESS-MACHINE указан соответствующий необязательный 
параметр. 

Процесс-машину можно представить как состоящую из про¬ 
грамм обработки команд (собственно «машины»), стека запи¬ 
сей активации, области распределяемой памяти и регистратора 
состояния. Однако в рамках архитектуры понятие «процесс-ма¬ 
шина» детализируется лишь в степени, необходимой для описа¬ 
ния команд системы. 

ПОРТ 

Порт является абстрактным объектом в системе, служащим для 
установления связей между двумя или большим числом про¬ 
цессов в целях их согласованной совместной работы. Объект 
«порт» создается командой CREATE-PORT, а разрушается или 
командой DESTROY, или при уничтожении породившей его 
процесс-машины, если в команде CREATE-PORT указан соот¬ 
ветствующий необязательный параметр. О наличии объекта 
«порт» в системе можно судить только по семантике (смысло¬ 
вому содержанию) двух команд — SEND и RECEIVE. Никакой 
дополнительной информации об этом объекте в описании рас¬ 
сматриваемой архитектуры не приводится. 

ФОРМАТЫ КОМАНД 
И СПОСОБЫ АДРЕСАЦИИ 

Формат машинной команды состоит из поля кода операции и 
одного или нескольких следующих за ним адресных полей. 
В некоторых командах имеется одно поле адреса, в других — 



фиксированное число этих полей (до 5). Имеются также коман¬ 
ды, число адресных полей в которых может меняться. 

ПОЛЕ КОДА ОПЕРАЦИИ 

Первым полем любой команды является поле ее кода операции. 
Длина этого поля не является одной и той же для всех команд. 
Она выбирается в зависимости от относительной частоты ис¬ 
пользования той или иной команды. Так, в 15 наиболее рас¬ 
пространенных командах для этого поля отведен 1 токен, для 
следующих по частоте использования 15 команд — 2 токен, 
а для остальных — 4 токен. 


АДРЕСНЫЕ ПОЛЯ 

В системе различают семь типов адресных полей, объединяемых 
в три группы полей: адрес операнда, адрес команды и непо¬ 
средственные данные. Адрес операнда предназначен для обра¬ 
щения к операндам в адресном пространстве. Имеется шесть 
разновидностей адреса операнда. 

Адрес ячейки. Адрес ячейки занимает N токен и служит для 
ссылок на ячейки адресного пространства (здесь N — значение 
содержимого поля длины адреса ячейки, входящего в заголовок 
модуля). Например, если значение N(CAS) равно 2, адрес опе¬ 
ранда, равный ІА, указывает на ячейку, начинающуюся с 
26-го токена в адресном пространстве модуля. Адреса ячеек не 
могут использоваться для обращения к массивам или записям. 
Литерал. Поле, содержащее адрес операнда в форме литерала, 
(состоит из N токен, в которых находятся нули, и следующего 
за ними 1 токен, в котором хранится число от 0 до 9. Например, 
если N(CAS)=2, адрес операнда, равный 004, является лите¬ 
ралом со значением +4. При использовании литерала в логи¬ 
ческих командах он может принимать одно из двух значений: 
0 (ложно) и 1 (истинно). 

Адрес элемента массива. Адрес элемента массива ісостоит из 
D+1 полей (предполагается, что массив имеет размерность D). 
Первое поле служит для хранения адреса ячейки массива или 
адреса компонента записи для массива (т. е. для массива как 
компонента записи). В следующих D полях должны распола¬ 
гаться литералы либо адреса ячеек «целое число» или «пара¬ 
метр», если содержимое последних определяется как целочис¬ 
ленное значение. Например, если адрес ячейки А «массив» ра¬ 
вен 20іб, адрес переменной (адрес ячейки) I равен ЗСіб и N = 
=2іб, то адрес операнда для А (4, I) равен 200043Сі 6 . Если 
N = 3i6, то адрес операнда принял бы значение, равное 
020000403Сі 6 . 
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Адрес массива. Адрес массива относится ко всему массиву. 
Способ его записи подобен записи адреса элемента массива,, 
только во всех полях для индексов отдельных компонентов раз¬ 
мерности должен быть записан символ *. Этот символ представ¬ 
ляется полем типа литерал со значением, равным Fi 6 (1111), 
Тогда адрес упомянутого выше массива А имеет вид 2000F00Fi 6 , 

В соответствии с принятыми формами записи адресов имеет¬ 
ся принципиальная возможность для обращения к кросс-секци¬ 
ям массивов, например, можно пользоваться выражениями вида 
А(*, I) языка ПЛ/1. Однако реализация этой возможности в си¬ 
стеме SWARD не предусмотрена. 

Адрес компонента записи. Этот адрес состоит из двух полей. 
Первое из них имеет форму адреса ячейки, адреса элемента 
массива или адреса массива для записи (последние два вари¬ 
анта относятся к случаям, когда запись является элементом' 
массива). Второе поле предназначено для адреса компонента. 
Бели компонент не является массивом, это поле состоит из 3 то¬ 
кен, в которых находится смещение дескриптора данного ком¬ 
понента от начала тега записи. Если компонент нредставляет 
собой массив, то вслед за указанной информацией (3 токен^ 
следует Die литералов или адресов ячеек «целое число» либо 
«параметр», если содержимое последней определяется как це¬ 
лочисленное значение (для адресации элемента), или Di 6 значе¬ 
ний * (для адресации всего массива). Отметим, что обращение к: 
компонентам, которые сами являются записями, выполняется с 
помощью адресов компонентов записи, а обращение к компо¬ 
нентам компонентов записей происходит как к компонентам за¬ 
писи, внешней по отношению ко всем другим записям. 

Адрес записи. Адрес записи относится полностью ко всей запи¬ 
си. Форма представления адреса этого типа совпадает с формой 
адреса компонента записи. Но в поле адреса компонента, со¬ 
стоящем, как отмечалось выше, из 3 токен, находятся нули. 

При отсутствии специального указания в качестве адреса 
операнда в командах можно использовать любую из его шести 1 
рассмотренных здесь форм. Не допускается только использова¬ 
ние литерала в качестве операнда принимающего поля коман¬ 
ды. Под операндом понимают данные, к которым обращается 
команда, использующая адрес операнда (возможно, через ячей¬ 
ку «параметр» или «косвенный доступ к данным»). Операндом 
принимающего поля называют операнд, значением которого яв¬ 
ляется результат операции. 

Рассмотренные выше типы содержимого адресных полей об¬ 
разуют одну из трех возможных разновидностей адресов запи¬ 
си. Ко второй разновидности относится адрес команды. Этот 
адрес занимает область памяти М. токен (М — значение содер¬ 
жимого поля длины адреса команды в заголовке модуля) и 
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.позволяет ссылаться на команды, принадлежащие области ко¬ 
манд. 

К последней разновидности адресов записи относится содер¬ 
жимое поля так называемых непосредственных данных. Это 
поле длиной 1 или 2 токен содержит не адрес, а некоторую ве¬ 
личину, которая непосредственно используется в команде. По¬ 
скольку эти операнды находят применение в ограниченном чис- 
-ле команд и для специальных целей, более подробно они рас¬ 
сматриваются ниже при описании соответствующих команд. 

ПРАВИЛА ФОРМИРОВАНИЯ 
АДРЕСОВ ОПЕРАНДОВ 

'С помощью адресов операндов могут выполняться сложные 
способы адресации, позволяющие, например, с помощью единст¬ 
венного адреса обратиться к компоненту массива записей, яв¬ 
ляющегося в свою очередь компонентом записи. Подобная 
гибкая форма адресации требует особого внимания к порядку 
указания отдельных элементов адреса, поскольку допускается 
даже рекурсивное образование адресов, при котором, напри¬ 
мер, адрес элемента массива может содержать адрес компонен¬ 
та записи или наоборот. 

Введем сокращенные обозначения для рассмотренных выше 
типов адресов операндов: 

са — адрес ячейки, 
lit —литерал, 

аеа— адрес элемента массива, 
аа —адрес массива, 
гса — адрес компонента записи, 
га — адрес записи. 

Пусть также х(а), х(і) и х(г) обозначают адрес типа х, 
^используемый для обращения к данным типа массив, целое чис¬ 
ло и запись соответственно. Тогда 
аеа ::= са(а) еа...|гса(а) еа... 
аа ::= са(а)*...|гса(а)*... 
гса ::= real ра 
га ::= real 000 

хде 

.ра ::= cdo|cdo ea...|cdo*... 
vea ::= ca(i) |lit 

* ::=0F"n P H N=1"|00F "при N=2"|... 
real ::=» ca(r) |aea(r) |aa(r) 
cdo ::="3 токен с ненулевым значением" 

Примеры структуры адресов операндов, формируемой в соответ¬ 
ствии с этими правилами, приведены в табл. 14.1. 
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Таблица 14.1. Примеры адресов операндов (массивы предполагаются 
одномерными) 


Тип адресуемых данных 

Тип ячейки, 
которой при¬ 
надлежат 

Тип адреса 
операнда 

Структура адре¬ 
са операнда 

Данные простого типа 


са 

са 

Литерал 

— 

lit 

lit 

Данные простого типа 

Все элементы, являющиеся дан- 

Массив 

аеа 

са еа 

ными простого типа 

Массив 

аа 

са* 

Запись 

_ 

га 

са 000 

Компонент — не массив 

Запись 

гса 

са cdo 

Компонент — не массив 

Массив 

записей 

гса 

са еа cdo- 

Все компоненты (срез) 

Массив 

записей 

гса 

са* cdo 

Запись 

Массив 

записей 

га 

са еа 000 

Все записи 

Элемент (не массив) массива — 

Массив 

записей 

га 

са* 000 

компонента 

Все элементы (не массивы) мас¬ 

Запись 

аеа 

са cdo еа 

сива — компонента 

Компонент (не массив) записи, 
являющейся элементом масси¬ 

Запись 

аа 

са cdo* 

ва — компонента 

Все компоненты (не массивы) за¬ 
писи, являющейся элементом 

Запись 

гса 

са cdo еа cdo 

массива — компонента 

Запись, являющаяся элементом 

Запись 

гса 

са cdo* cdo 

массива — компонента 

Запись 

га 

са cdo* 000 


Общие принципы формирования адресов могут быть сфор¬ 
мулированы также несколько иначе. Общий адрес разбивается 
на элементарные компоненты. Первый элементарный компонент 
адреса должен относиться к ячейке, содержащей адресуемые 
данные, а последний элементарный компонент адреса должен 
относиться собственно к адресуемым данным. Иначе говоря, 
если ссылка устанавливается на какие-либо компоненты ячей¬ 
ки, то каждый последующий элементарный компонент адреса 
должен относиться к следующему, более глубокому уровню 
вложения адресуемого компонента. 

ОБРАБОТКА ОШИБОК 
В СИСТЕМЕ SWARD 

Одной из основных задач машины рассматриваемой архитек¬ 
туры является обнаружение определенного класса ошибок, со¬ 
вершаемых при программировании. Поэтому велико значение 
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применяемых в системе методов обнаружения ошибок и инфор¬ 
мирования о них пользователя. В этом разделе рассматривают¬ 
ся типы ошибок, которые способна выявлять система, инфор¬ 
мация об ошибках, передаваемая системой соответствующему 
процессу, и средства взаимодействия между процессом и систе¬ 
мой при обработке ошибок. 


ТИПЫ РЕГИСТРИРУЕМЫХ ОШИБОК 

Ниже перечисляются типы ошибок, регистрируемых в машине 
SWARD и разъясняются условия их возникновения. При вы¬ 
полнении команды может быть одновременно зарегистрирова¬ 
но несколько ошибок, однако архитектура не содержит средств 
указания ни первой из встретившихся ошибок, ни порядка, 
в котором были обнаружены ошибки отдельных типов. 

Ошибка типа 1 — неверный код операции — регистрируется 
при попытке выборки команды с неправильным кодом операции 
или при выходе за пределы области, отведенной под команды, 
при попытке адресации команды. 

Ошибка типа 2 — неправильная адресация — возникает в од¬ 
ной из следующих ситуаций: 

1) используемый адрес ячейки выходит за пределы для про- 
станства адресов данного модуля или относится не к той части 
(статической вместо динамической или наоборот) адресного 
пространства; 

2) индекс элемента массива не является целым числом; 

3) ошибочный адрес операнда; 

4) внешнее обращение к компонентам модуля (по командам 
LINK или COMPUTE-ENTRY-CAPABILITY) не соответствует 
установленным правилам адресации; 

5) ошибка при обработке адреса ячейки (например, наруше¬ 
ны правила использования ячейки «косвенный доступ к дан¬ 
ным») ; 

6) наличие замкнутой петли адресации при использовании 
косвенных потенциальных адресов (например, указатель ссыла¬ 
ется сам на себя). 

Ошибка типа 3 — данные неизвестного формата — регистри¬ 
руется при обращении к ячейке с нераспознаваемым типом дан¬ 
ных или значением. 

Ошибка типа 4 — нарушение защиты от несанкционирован¬ 
ного доступа — имеет место в одном из следующих случаев: 

1) обращение к ячейке (для записи, чтения или уничтоже¬ 
ния) посредством потенциального адреса с кодом доступа, не 
соответствующим запрошенной операции; 

2) непосредственный запрос на уничтожение части памяти, 
принадлежащей записи активации или модулю; 
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3) попытка программы изменить значение переданного моду¬ 
лю фактического параметра, при работе с которым санкциони¬ 
ровано только «чтение»; 

4) попытка программы копировать содержимое ячейки «ука¬ 
затель» при отсутствии соответствующего санкционирующего 
признака в коде доступа. 

Ошибка типа 5 — недействительный потенциальный адрес — 
возникает при использовании потенциального адреса, содержа¬ 
щего логический адрес, который машине не известен (напри¬ 
мер, объект, к которому производится ссылка, уничтожен). 

Ошибка типа 6 — выход индекса за допустимые границы — 
регистрируется при обращении к элементу массива, когда зна¬ 
чение индекса этого элемента выходит за допустимые пределы, 
или при обращении к элементу строки с порядковым номером, 
превышающим текущую длину строки. 

Ошибка типа 7 — неверный тип операнда — имеет место, ког¬ 
да тип операнда не соответствует допустимому для данной ко¬ 
манды типу (типам) или при адресации объектов «память 
данных», недопустимых к использованию данной командой. 

Ошибка типа 8 — неопределенный операнд — возникает при 
попытке использовать значение операнда, которое задано как 
«неопределенное». Этого состояния не бывает при выполнении 
команды DEFINED-BRANCH-FALSE, которая, по существу, 
является средством проверки неопределенности значения опе¬ 
ранда. 

Ошибка типа 9 — несовместимые операнды — регистрируется, 
если два или несколько операндов одной и той же команды 
взаимно несовместимы. Условия совместимости операндов при¬ 
водятся в определениях соответствующих команд. Ошибка та¬ 
кого рода может быть, в частности, зарегистрирована при вы¬ 
полнении команды ACTIVATE, если тип ячейки «параметр» не¬ 
совместим с типом ячейки, содержащей соответствующий фак¬ 
тический параметр, а также в случае выполнения команд 
RECEIVE и SEND при несоответствии типов операндов для 
данных при их передаче и приеме. Это же состояние регистри¬ 
руется, если атрибуты ячейки «косвенный доступ к данным» не 
согласуются с атрибутами адресуемых данных. 

Ошибка типа 10 — переполнение — фиксируется, когда опе¬ 
ранд, указывающий местоположение результата выполнения 
команды, является адресом ячейки, размер которой недостато¬ 
чен для размещения этого результата. Для операндов арифмети¬ 
ческих операций переполнение наступает, если происходит по¬ 
теря ненулевых .старших разрядов числа. Аналогичная ситуация 
возникает при выполнении операций над числами с пла¬ 
вающей точкой, когда показатель степени результата оказыва¬ 
ется больше чем 99. Если операнды являются строками симво- 
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лов, то переполнение наступает в тех случаях, когда размер па¬ 
мяти, предусматриваемый командой для хранения результата, 
недостаточен для строки, формируемой этой командой. 

Ошибка типа 11 — потеря значимости — регистрируется тог¬ 
да, когда результат выполнения операции над числами с пла¬ 
вающей точкой является числом, показатель степени которого 
меньше чем —99. 

Ошибка типа 12 — некорректное деление — происходит при 
попытке деления на нуль. 

Ошибка типа 13 — недействительный модуль — возникает 
при выполнении команды CREATE-MODULE, если допускается 
неправильный формат внешнего модуля. 

Ошибка типа 14 — недопустимая передача управления — 
обусловлена разнообразными причинами при выполнении ко¬ 
манды, передающей управление. Наиболее часто подобная 
ошибка регистрируется при попытке передачи управления за 
пределы области команд данного модуля. 

Ошибка типа 15 — неправильное число передаваемых дан¬ 
ных — возможна при выполнении команды ACTIVATE, если 
количество формальных параметров, задаваемое при описании 
программы, не равно количеству фактически передаваемых па¬ 
раметров. Кроме того, она возникает при выполнении команд 
RECEIVE и SEND, когда количество посылаемых параметров 
(определяемых командой SEND) не соответствует количеству 
принимаемых параметров (определяемых командой RECEIVE). 

Ошибка типа 16 — недопустимое преобразование данных — 
регистрируется при выполнении команды CONVERT, если опе¬ 
ранды не удовлетворяют требованиям, предъявляемым к ним 
правилами согласования, которые определены в описании ко¬ 
манды CONVERT. 

Ошибка типа 17 — трассировка — наблюдается при выполне¬ 
нии команд в модуле, для которого установлен режим трасси¬ 
ровки (см. команду TRACE в гл. 15). 

Ошибка типа 18 — выход за пределы допустимых значе¬ 
ний — может быть зарегистрирована как результат сравнения 
значений операндов команды RANGE-CHECK (см. гл. 15). 

Ошибка типа 19 — недостаточный объем памяти — возника¬ 
ет, если память размером AM (см. гл. 15), имеющаяся в распо¬ 
ряжении процесс-машины, недостаточна для объекта, которому 
машина пытается ее динамически выделить, или если машина 
не способна получить необходимый объем физической памяти. 

Ошибка типа 20 — недопустимая обработка ошибок — ре¬ 
гистрируется в следующих случаях: 

1) при попытке выполнить команду CONTINUE при наличии 
ошибки, не допускающей продолжение выполнения команд про¬ 
граммы; 
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2) при попытке выполнения команды RAISE-FAULT с недо¬ 
пустимым кодом ошибки; 

3) при попытке выполнения команд CONTINUE и TRANS¬ 
FER-FAULT вне программ обработки ошибок. 

Ошибка типа 21 —имитация ошибки — происходит, когда 
другая процесс-машина с помощью команды CONTROL-PRO¬ 
CESS-MACHINE имитирует для данной процесс-машины воз¬ 
никновение ошибки. 

Ошибка типа 22 — неопределенный доступ к операнду — 
имеет место, когда содержимое ячейки, не являющейся операн¬ 
дом команды, используется для определения местоположения 
операнда, причем это содержимое имеет неопределенное значе¬ 
ние. Это может произойти при обращении к ячейкам следую¬ 
щих типов: 

1) ячейке «параметр:», содержимое которой не было установ¬ 
лено в результате вызова текущего модуля по команде ACTI¬ 
VATE; 

2) ячейке «косвенный доступ к данным», используемой для 
переадресации к указателю, значение которого не определено; 

3) ячейке «массив» с неопределенным значением индекса; 

4) ячейке «указатель», содержащей косвенный потенциаль¬ 
ный адрес, определяемый в свою очередь через указатель с не¬ 
определенным значением. 

ПРОГРАММА ОБРАБОТКИ ОШИБОК 

Каждому типу перечисленных выше ошибок в рассматриваемой 
вычислительной системе присвоен определенный номер. Этот 
номер соответствует некоторому двоичному разряду в поле кода 
ошибки, находящемуся в заголовке модуля. Например, ошибке 
типа 1 (неверный код операции) соответствует разряд 1 в поле 
кода ошибки. Содержимое этого разряда, равное 1, указывает 
на необходимость обработки для данного модуля ошибок типа 
«неверный код операции». Нулевой (первый по порядку) двоич¬ 
ный разряд поля кода ошибки в заголовке модуля используется 
для указания на необходимость обработки ошибок типа 28— 
255, т. е. программно-определяемых ошибок (см. описание ко¬ 
манды RAISE-FAULT). 

При появлении ошибки некоторого типа система пытается 
вызвать программу обработки ошибок текущего модуля данно¬ 
го процесса. (По соглашению команды этой программы распо¬ 
лагаются, начиная с первой команды модуля). Программа об¬ 
работки ошибок будет вызвана, если разрешена обработка оши¬ 
бок данного типа (содержимое соответствующего разряда поля 
кода ошибки равно 1). В противном случае система пытается 
вызвать другую программу обработки ошибок, для чего про¬ 
сматривает в обратном порядке стек активных модулей данно- 
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го процесса до отыскания такого модуля, в котором обработка 
ошибок данного типа разрешена. Если такой модуль найти не 
удается, система уничтожает данную процесс-машину. 

Предполагается (хотя это и не обязательное требование), 
что первым вызываемым модулем процесса является специаль¬ 
ный модуль, генерируемый компилятором или операционной си¬ 
стемой, в котором разрешена обработка ошибок всех типов. 

Вызов программы обработки ошибок происходит как вызов 
внутренней процедуры. Поэтому такая программа имеет воз¬ 
можность работы с адресным пространством того модуля, кото¬ 
рому принадлежит. (При этом запись активации соответствует 
последнему вызову этого модуля в данной процесс-машине.) 
При передаче управления модулю система передает ему также 
следующие пять параметров: 

1) целое число, равное номеру типа ошибки; 

2) указатель модуля, при выполнении которого обнаружена 
ошибка (в коде доступа указателя имеется разрешение на ко¬ 
пирование) ; 

3) указатель точки входа модуля, с которой началось его 
выполнение (в коде доступа этого указателя имеется разреше¬ 
ние на копирование); 

4) ячейку типа «поле токенов», длина которой равна 5, а со¬ 
держимое-адрес команды, вызвавшей состояние ошибки; 

5) ячейку типа «поле токенов», длина которой равна 6. 

Программе обработки ошибок разрешено только читать пе¬ 
редаваемые ей фактические параметры. Значение последнего из 
них зависит от типа встретившейся ошибки. В частности, для 
ошибки «недействительный модуль» в этом параметре переда¬ 
ется код типа ошибки (е)сли причиной этой ошибки не явля¬ 
ется команда RAISE-FAULT). При наличии ошибки «имитация» 
в указанном параметре находится код, заданный в команде 
CONTROL-PROCESS-iMACHINE, которая вызывает появление 
ошибки этого типа (если причиной ее появления не является 
команда RAISE-FAULT). При обнаружении ошибки «трасси¬ 
ровка» в данном параметре передается информация о событии, 
вызвавшем это состояние. В остальных случаях в указанном 
параметре находятся первые 6 токен команды, при выполнении 
которой обнаруживается ошибка. 

В системе имеются также команды, позволяющие динами¬ 
чески разрешать и отменять в пределах модуля обработку оши¬ 
бок отдельных типов; генерировать в программе в явной форме 
состояния ошибки; выходить из программы обработки ошибок 
с продолжением выполнения команд, следующих за командой, 
вызвавшей появление ошибки; повторять выполнение такой 
команды или передавать полномочия по обработке ошибки про- 
грамме более высокого уровня. 
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Ошибки, возникающие во время работы программы обработ¬ 
ки ошибок, обрабатываются так же, как и любые другие ошиб¬ 
ки. Различие заключается лишь в том, что с целью предотвра¬ 
щения бесконечных повторных входов в указанную программу 
поиск подходящей программы обработки ошибок начинается с 
модуля, вызвавшего модуль, содержащий программу обработки 
ошибок, при выполнении которой регистрируется ошибка. 
Процесс обработки ошибок имеет структуру вложенных проце¬ 
дур: если ошибка обнаружена во время работы программы об¬ 
работки ошибок А и обрабатывается программой обработки 
ошибок В, которая по команде RETURN или CONTINUE воз¬ 
вращает управление программе А, то последняя оказывается в 
своем предшествующем состоянии (т. е. параметры, передавав¬ 
шиеся программе А, оказываются вновь доступными ей в неиз¬ 
менном, первоначальном виде). 

Будучи совокупностью команд, программа обработки оши¬ 
бок должна начинаться с первой команды модуля. Поэтому в 
начале модуля располагаются либо команды указанной про¬ 
граммы (начиная с команды LACT), либо команда перехода 
к ней. 


СОСТОЯНИЕ ПРОЦЕССА 
ПОСЛЕ ОБНАРУЖЕНИЯ ОШИБКИ 

Особого внимания при организации системы обработки ошибок 
заслуживает состояние процесса в момент обнаружения ошиб¬ 
ки. В большинстве случаев команда, при выполнении которой 
обнаруживается ошибка, не влияет на состояние процесса. 
Программа обработки ошибок завершает свою работу одной из 
следующих четырех команд: 

1) LOCAL RETURN — передача управления на повторное 
выполнение команды, обнаружившей ошибку; 

2) CONTINUE — передача управления команде, которая вы¬ 
полнялась бы следующей, если бы не была обнаружена ошибка; 

3) RETURN — уничтожение записи, активации данного и 
всех последующих модулей с передачей управления модулю, 
который вызвал данный; 

4) TRANSFER-FAULT — завершение работы данной про¬ 
граммы обработки ошибок, инициирование поиска и передача 
управления аналогичной программе более высокого уровня. 

Из этих общих правил имеется несколько исключений: 

1) при выдаче команды LRETURN для выхода из состояния 
обработки ошибок, инициированного командой RAISE-FAULT, 
управление передается команде, следующей за командой 
RAISE-FAULT. 
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2) ’ если ошибка регистрируемся при обработке ячеек «поле», 
«запись» или «массив», то элементы этих ячеек, обработанные 
до обнаружения ошибки, получают новые значения, а значения 
остальных элементов не изменяются. 

3) при выполнении в программе обработки ошибок команды 
CALL во избежание превращения стека активации в дерево, 
т, е. запоминающее устройство древовидной структуры, система 
ликвидирует все записи активации, расположенные в стеке ак¬ 
тивации под текущей записью. 

НАБОР КОМАНД СИСТЕМЫ SWARD 

В этом разделе рассматривается основное назначение ко¬ 
манд системы SWARD. Детальное описание каждой команды 
дано в гл. 15. 


КОМАНДЫ ОБЩЕГО НАЗНАЧЕНИЯ 

В рассматриваемой системе имеются четыре команды общего 
назначения: MOVE, CONVERT, UNDEFINE и DISPLAY- 
OPERAND TYPE. Операндами этих команд могут быть ячейки, 
содержащие простые скалярные величины, массивы, строки, а 
также представляющие так называемые срезы, поля или записи. 
Команда MOVE используется для пересылки значения одного 
операнда в ячейку другого операнда. Команда CONVERT вы¬ 
полняет те же действия, что и команда MOVE, а также функ¬ 
цию преобразования данных. Например, при попытке использо¬ 
вания команды MOVE для пересылки .символьных данных 
в ячейку, предназначенную для целого числа, эта команда не 
выполняется и регистрируется ошибка «несовместимые операн¬ 
ды». Если же воспользоваться командой CONVERT, то указан¬ 
ная задача будет решена: символьные данные преобразуются в 
целое число в соответствии с заданными правилами преобразо- 
вания. 

Команда UNDEFINE используется для установки признака 
неопределенности значения операнда. Команда DISPLAY- 
OPERAND-TYPE позволяет получать информацию об атрибу¬ 
тах операнда. Этой командой можно, в частности, пользовать¬ 
ся для определения текущих атрибутов ячеек с динамически 
определяемыми типом, размером и границами. 

АРИФМЕТИЧЕСКИЕ КОМАНДЫ 

В эту группу входят команды: ADD, SUBTRACT, MULTIPLY, 
DIVIDE, REMAINDER, ABSOLUTE, COMPLEMENT (по этой 
команде выполняется операция только над знаком операнда). 
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Каждая из первых пяти команд имеет два операнда; результат 
операции размещается на месте первого операнда. Команды 
ABSOLUTE и COMPLEMENT содержат по одному операнду. 
Операнды могут быть скалярами или массивами с числовыми 
значениями. 


КОМАНДЫ СРАВНЕНИЯ И ПЕРЕХОДА 

Формат команд EQUAL-BRANCH-FALSE, NOT-EQUAL- 
BRANCH-FALSE, LESS-THAN-BRANCH-FALSE, GREATER- 
THAN-BRANCH-FALSE, LESS-THAN-OR-EQUAL-BRANCH- 
FALSE и GREATER-THAN-OR-EQUAL-BRANCH-FALSE пред¬ 
усматривает наличие двух операндов и адрес команды. Выпол¬ 
нение этих команд сводится к сравнению значений обоих опе¬ 
рандов. Если результат сравнения отрицательный, то управле¬ 
ние передается по указанному адресу команды. В общем случае 
операндами этих команд может быть содержимое ячеек любого 
типа (например, указатели, строки символов, массивы, записи). 
К этой же группе принадлежат команды: DEFINED- 
В RANCH-FALSE, ITERATE, ITERATE-REVERSE и CASE. Пер¬ 
вая из них служит для проверки, определено ли значение операн¬ 
да. Две другие команды предназначены для организации циклов, 
а последняя команда — для передачи управления при наличии 
многих направлений, осуществляемой в зависимости от значе¬ 
ния целого или так называемого порядкового числа. 


ЛОГИЧЕСКИЕ КОМАНДЫ 

К логическим командам относятся команды AND, OR и NOT. 
Операндами этих команд могут быть порядковые числа или мас¬ 
сивы таких чисел. 


КОМАНДЫ ПОИСКА 
И РАБОТЫ СО СТРОКАМИ ДАННЫХ 

В то время как многие машинные команды могут работать 
с операндами, представляющими собой строки символов, су* 
ществуют специальные команды, выполняющие операции толь¬ 
ко над данными такого типа. Операндами этих команд могут 
быть поля или строки символов либо токенов. 

По команде CONCATENATE значение одного операнда при¬ 
соединяется к концу значения другого операнда. Команда 
MOVE-SUBSTRING позволяет часть строки, выделенную в од¬ 
ном операнде, поместить на место части строки другого операн¬ 
да. С помощью команды INDEX в указанной строке может быть 
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проведен поиск заданной части строки. По команде LENGTH 
можно определить текущую длину строки. 

К этой же группе команд относится команда SEARCH. Эта 
команда позволяет в массиве или в срезе массива найти эле¬ 
мент с заданным значением (определить индексы этого эле¬ 
мента). 

КОМАНДЫ УПРАВЛЕНИЯ 

Команды управления используются для безусловной передачи 
управления: для организации передачи управления между мо¬ 
дулями пользуютіся командами CALL, ACTIVATE и RETURN, 
для организации обращения к внутренним подпрограммам дан¬ 
ного модуля — командами LOCAL-CALL, ACTIVATE и LOCAL- 
RETURN, для изменения порядка выполнения команд в мо¬ 
дуле—командой BRANCH. 

В команде CALL задается имя элемента, которому переда¬ 
ется управление (точка входа в модуль), и список фактических 
параметров. Для части этих параметров может быть определен 
признак того, что они могут только читаться, т. е. вызываемый 
модуль не может ни изменить, ни освободить их. Команда 
CALL распределяет для переменных память, отводимую в ди¬ 
намической части адресного пространства вызываемого модуля, 
и передает управление в заданную точку входа. Если вызывае¬ 
мый модуль должен извне получать параметры, то до обраще¬ 
ния к ним в этом модуле должна быть выдана команда 
ACTIVATE. В команде определяется список получаемых пара¬ 
метров. При выполнении этой команды проверяется соответст¬ 
вие между передаваемыми фактическими параметрами и при¬ 
нимающими формальными, а также осуществляется инициализа¬ 
ция последних (передаются адреса параметров). По команде 
RETURN освобождается память динамической части адресного 
пространства, и управление возвращается вызывающему мо¬ 
дулю. 

В команде LCALL 1 ) в форме адреса команды задаются ад¬ 
рес внутренней процедуры и список фактических параметров. 
Если процедура получает значения параметров извне, то обра¬ 
щению к ним должна предшествовать команда ACTIVATE. По 
команде LCALL не выполняется какого-либо динамического 
распределения памяти, т. е. потребности внутренних процедур 
обеспечиваются средствами программного обеспечения не в 
полной мере. Поэтому функции выделения памяти и определе¬ 
ния области действия имен переменных при необходимости 

*) Сокращенное название программы LOCAL-CALL. Аналогично полным 
названием команды LRETURN является LOCAL-RETURN. Список сокраще¬ 
ний приведен в описаниях команд в гл. 15. — Прим, перев. 



СИСТЕМА SWARD 345 


возлагаются на компилятор. По команде LRETURN произво¬ 
дится возврат управления из данной процедуры команде, сле¬ 
дующей за последней выполнявшейся командой LCALL. 

КОМАНДЫ АДРЕСАЦИИ 

Эта группа команд связана с операциями над указателями, по¬ 
тенциальными адресами и объектами системы. Команда COM¬ 
PUTE-CAPABILITY для указанного операнда формирует его 
потенциальный адрес, команда COMPUTE-INDIRECT- 
CAPABILITY позволяет получить косвенный потенциальный ад¬ 
рес для заданного указателя. Команда CHANGE-ACCESS пред¬ 
назначена для сужения прав доступа (включения дополнительных 
ограничений в код доступа) в потенциальном адресе. С помо¬ 
щью команды CHANGE-LOGICAL-ADDRESS переименовыва¬ 
ют существующий объект, т. е. назначают новый логический 
адрес для объекта. Команда COMPUTE-CAPABILITY- 
EXTERNALLY позволяет сформировать потенциальный адрес 
для указанного операнда из другого модуля, возможно, даже 
~ ^c.uwicioHH с записью активации, связанной с другой процесс- 
машиной. Эта команда предназначена прежде всего для отладки 
программ. 

По команде ALLOCATE создается объект «память данных», 
предназначенный для ячейки определенного типа на случай ее 
возможного создания в процессе работы системы. По команде 
DESTROY можно уничтожить объект любого типа. 

Команда CREATE-MODULE позволяет на основании внеш¬ 
него модуля получить объект «модуль». С помощью команды 
COMPUTE-ENTRY-CAPABILITY можно рассчитать потенци¬ 
альный адрес точки входа указанного модуля. Команда LINK 
присваивает значение указателю в некотором объекте «мо¬ 
дуль». Команды COMPUTE-ENTRY-CAPABILITY и LINK ис¬ 
пользуются для организации взаимной связи модулей про¬ 
граммы. 

Если воспользоваться командой DESCRIBE-CAPABILITY, 
а в качестве операнда задать указатель, можно получить ряд 
параметров соответствующего потенциального адреса и самого 
адресуемого объекта. 

КОМАНДЫ УПРАВЛЕНИЯ ПРОЦЕСС-МАШИНАМИ 

Эта группа команд тесно связана с понятием процесс-машин 
системы. 

Команда CREATE-PROCESS-MACHINE позволяет создать 
процесс-машину, передать ей требуемый объем имеющейся 
в наличии памяти и начать ее выполнение с заданной точки 
входа модуля. TRANSFER-AM позволяет перераспределить 
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объем памяти между двумя процесс-машинами. С помощью 
команды CONTROL-PROCESS-MACHINE одна процесс-маши¬ 
на может останавливать и запускать другую процесс-машину, 
а также формировать условия появления ошибки в другой про¬ 
цесс-машине или изменять приоритет последней. Посредством 
команды COMPUTE-PROCESS-MACHINE-CAPABILITY мож¬ 
но получить потенциальный адрес процесс-машины, обрабаты¬ 
вающей данную команду. При использовании команды DELAY 
приостанавливается выполнение данной процесс-машины на 
указанный интервал времени. 

Команды GUARD и UNGUARD позволяют защищать кри¬ 
тические области в последовательностях команд от одновремен¬ 
ной обработки несколькими процесс-машинами, что облегчает 
построение мониторов. 

Команды CREATE-PORT, SEND и RECEIVE используются 
для организации связи между процессами по данным. С по¬ 
мощью команды SEND сообщение может быть послано в порт, 
а с помощью команды RECEIVE — получено из него. 

КОМАНДЫ ОТЛАДКИ 

Эта последняя группа команд связана с отладкой программ и 
обработкой ошибок. С помощью команд ENABLE и DISABLE 
программа может динамически устанавливать и отменять ре¬ 
гистрацию ошибок определенного типа, которые подлежат про¬ 
граммной обработке ошибок данного модуля. Посредством ко¬ 
манды RAISE-FAULT можно явно запросить регистрацию 
ошибки и инициировать работу обработчиков ошибок. По ко¬ 
манде RANGE-CHECK можно задать диапазон значений опе¬ 
ранда и условие генерирования ошибки, если текущее значение 
операнда выходит за пределы указанного диапазона. 

Включение команды CONTINUE в обработчик ошибок по¬ 
зволяет вернуться к выполнению команд модуля, в котором 
была зарегистрирована ошибка, а именно передать управление 
команде, непосредственно следующей за той, которая привела 
к ошибке. (Если требуется повторить команду, вызывающую 
возникновение ошибки, следует воспользоваться командой 
LRETURN.) Если во время работы данной программы обра¬ 
ботки ошибок появляется необходимость выполнять обработку 
с помощью программы более высокого уровня, то соответствую¬ 
щая передача управления может быть выполнена с помощью 
команды TRANSFER-FAULT. 

Команда TRACE позволяет установить в указанном модуле 
режим трассировки команд перехода, команд передачи управ¬ 
ления модулям и внутренним процедурам и (или) команд 
MARKER. В таком случае выполнение команд отмеченных ти¬ 
пов будет сопровождаться регистрацией состояния «трассиров- 
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ка». Соответственно выполнение команды MARKER либо не 
будет ни в чем проявляться, либо будет сопровождаться инди¬ 
кацией состояния «трассировка», если режим маркерной трас¬ 
сировки разрешен соответствующими параметрами команды 
TRACE. 

ПРИМЕРЫ СТРУКТУРЫ МОДУЛЯ 

В целях иллюстрации особенностей архитектуры системы 
SWARD в данном разделе рассматриваются режимы компили¬ 
рования и выполнения нескольких программ. Текст первой про¬ 
граммы на языке ПЛ/1 соответствует второй программе для 
учебной ПЛ-машины (гл. 6), использовавшейся также для ил¬ 
люстрации архитектуры SYMBOL (гл. 9). Исходный текст про¬ 
граммы на языке ПЛ/1 имеет следующий вид: 

1 (SUBSCRIPTRAiNGE) : XYZ: PROCEDURE; 

2 DECLARE А (4) FLOAT DECIMAL (7); 

3 DECLARE (В, C) FIXED BINARY; 

4 В =4; 

5 A= 1; 

6 C=B+B*B; 

7 CALL ZZZ(B); 

8 A(B)=C; 

9 ZZZ: PROCEDURE (M); 

10 DECLARE M FIXED BINARY; 

11 C=M+M; 

12 END; 

13 END; 

Требуется сформировать строку токенов, которая содержит 
модуль 1 ), соответствующий этой программе, и проанализиро¬ 
вать его выполнение. Естественно было бы начать со структуры 
заголовка модуля, однако большинству его полей нельзя при¬ 
своить значения до окончания формирования всего модуля. По¬ 
этому построение заголовка будет временно отложено в пред¬ 
положении, что размер модуля невелик (в отношении как дан¬ 
ных, так и команд). Это позволяет принять значения CAS и 
IAS равными 2 (для записи адресов ячеек и команд отводится 
2 токен памяти). 

Прежде всего обратимся к адресному пространству модуля. 
Все переменные рассматриваемой программы подлежат вклю¬ 
чению в динамическую область адресного пространства. Адрес¬ 
ное пространство модуля имеет следующий вид: 

01 7011 1000B000004D7XXXXXX Array A (floating point) 

18 F800000 Integer В 

IF F800000 Integer С 

26 6005FXXXXXXX Parameter integer M 

•> По установленной терминологии SWARD — внешний модуль. — Прим. 


перев. 
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В левой колонке указаны адреса всех ячеек. Поскольку в ис¬ 
ходном тексте программы отсутствует присвоение переменным 
начальных значений, в соответствующих ячейках адресного про¬ 
странства указан признак неопределенного значения. 

Далее перейдем к рассмотрению машинных команд для ана¬ 
лизируемой программы. Для простоты воспользуемся пред¬ 
ставлением машинных команд на некотором условном языке 
типа языка ассемблера. Рядом с каждой командой, записанной 
на этом языке, будут приводиться соответствующая машинная 
команда и ее адрес (в форме адреса команды). 

Первой командой в модуле является команда ACTIVATE. 
В ней количество адресных полей непостоянно. Этим полям 
предшествует поле так называемых непосредственных данных, 
в котором задается число параметров. В остальные поля запи¬ 
сываются адреса параметров в форме адресов ячеек. Команда 
ACTIVATE присваивает параметрам начальные значения и про¬ 
веряет, идентичны ли типы каждого подобного формального 
параметра и соответствующего ему фактического параметра. 
Для рассматриваемой программы эта команда имеет вид 

ACT 0 (01: С00) 

Здесь С00 — запись данной команды в шестнадцатеричном 
коде, С — код операции, а 01 — адрес команды. Величина 00 
в поле непосредственного адреса означает отсутствие переда¬ 
ваемых в данный модуль параметров. 

После компилирования программы и ее загрузки получен¬ 
ный модуль (с именем XYZ) будет вызываться некоторым дру¬ 
гим модулем (например, операционной системой). Именно в 
этот момент формируется запись активации, выполняется копи¬ 
рование в нее динамической части адресного пространства и 
распределение памяти для элементов массива А. Однако ко¬ 
манды модуля XYZ могут обращаться к ячейкам так, как если 
бы они были физически размещены внутри данного модуля. 
Если адресуемая ячейка принадлежит динамической части ад¬ 
ресного пространства, машина автоматически преобразует этот 
адрес в адрес соответствующего элемента записи активации. 

После операторов описания в исходной программе располо¬ 
жен оператор В=4, реализуемый командой MOVE. В этой ко¬ 
манде используется литерал, поскольку присваиваемое В зна¬ 
чение 4 является целым числом, которое меньше 10. Команда 
формируется в виде 1 ) 

MOVE В, ‘4’ (04: 118004) 

! > Некоторому различию записи литерала в команде на условном языке 
ассемблера в данном тексте и в столбце комментариев к приводимому ниже 
полному тексту внешнего модуля не следует придавать значения. — Прим, 
перев. 
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где 18 — адрес ячейки В, а 004 — литерал. После выполнения 
данной команды содержимое ячейки В будет иметь значение, 
равное F000004. 

Оператор исходной программы А = 1 (пятая строка тейста) 
будет представлен следующей машинной командой: 

MOVE А, Т (OB: 10100F001) 

Величина 0100F в коде машинной команды является адре¬ 
сом массива А, причем 01 — адрес ячейки, a 00F — код знака *, 
играющего роль индекса. Следует обратить внимание на то, что 
в данном случае скалярная величина пересылается в массив. 
Кроме того, эта величина является целым числом, а элементы 
массива — десятичными числами с плавающей точкой. Систе¬ 
мой учитываются оба этих обстоятельства, и в каждый элемент 
массива А помещается десятичное число с плавающей точкой, 
равное 1. 

Для шестой строки исходного текста — оператора С = В + 
-+■ В*В — генерируются коды: 

MOVE С, В (13:1 1F18) 

MULT С, В (18: 41F18) 

ADD С, В (1D:21F18) 

Каждая из этих команд проверяет, определено ли значение 
исходного операнда, являются ли оба операнда арифметиче¬ 
скими (т. е. числами), достаточно ли по своим размерам место, 
куда должен быть записан результат операции. 

Седьмая строка исходного текста — оператор CALL. Для 
него генерируется следующая команда 1 ); 

LCALL ZZZ, 1, RW, В (22: 000В??01318) 

В этой команде 000В — код операции. Следующее поле в 
данной команде должно содержать адрес вызываемой в этом 
модуле внутренней процедуры. Значение этого адреса пока еще 
не определено. Содержимое следующего поля, имеющего длину 
2 токен и называемого полем непосредственных данных, указы¬ 
вает количество фактических параметров. Остальная часть ко¬ 
манды содержит информацию об адресах фактических пара¬ 
метров и формах доступа к каждому из них (только чтение или 
чтение — запись). В данном случае передается один параметр, 
к которому применимы операции чтения и записи. Команда 
LCALL, служащая для обращения к внутренней процедуре, 
в этом месте программы приостанавливает выполнение после- 


‘> Знак «?» обозначает временно не определенные части кода, получаю¬ 
щие значения после формирования последующих частей модуля, а символы 
RW указывают санкционируемые возможности чтения и записи. — Прим, 
перев. 
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довательности команд и передает управление команде с указан¬ 
ным адресом. 

Кодирование следующего оператора, расположенного в 
восьмой строке исходной программы, иллюстрирует возможно¬ 
сти, предоставляемые архитектурой системы SWARD для рабо¬ 
ты с элементами маосивов. В данном случае формируется сле¬ 
дующая команда: 

MOVE /А(В),С (2D: 101181 F) 

Здесь 0118 —адрес элемента массива, 01—адрес ячейки 
массива А, а 18 — адрес ячейки, содержимое которой исполь¬ 
зуется в качестве единственного индекса элементов этого одно¬ 
мерного массива. Отметим, что если при выполнении данной 
команды текущее значение В оказалось бы вне диапазона допу¬ 
стимых значений индекса А, то была бы зарегистрирована 
ошибка «выход за пределы допустимых значений». 

Поскольку оператор в девятой строке исходной программы 
является началом внутренней процедуры, необходимо «обойти» 
оператор этой процедуры. Для этого компилятор генерирует 
команду 

В ? (34: Е??) 

(До окончания процесса компилирования адрес перехода оста¬ 
ется временно не определенным.) Следующая генерируемая ко¬ 
манда имеет вид 

ACT 1,М (37: С0126); 

Эта команда задает количество параметров равным 1. При 
ее выполнении проверяется соответствие типов формального и 
передаваемого фактического параметров и присваивается на¬ 
чальное значение формальному параметру для возможности по¬ 
следующих обращений к нему как к фактическому параметру. 

Для оператора, расположенного в 11-й строке исходного 
текста, формируются команды 
MOVE С,М (ЗС: 11F26) 

ADD С,М (41: 21F26) 

Машина распознает, что операнды-источники в этих коман¬ 
дах по своему типу являются параметрами, автоматически вы¬ 
полняет переадресацию к фактическому параметру и использу¬ 
ет его значения в качестве значений этих операндов-источников. 

Программный модуль завершается командами 

LRETURN (46:000С) 

RETURN (4А:0А) 
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По команде LRETURN (ВОЗВРАТ ИЗ ВНУТРЕННЕЙ, 
ПРОЦЕДУРЫ) управление возвращается команде, следующей 
за последней выполнявшейся командой LCALL (в данном слу¬ 
чае управление получает команда с адресом 2D). Можно заме¬ 
тить, что адресом перехода в рассматривавшейся выше коман¬ 
де В должен быть адрес команды RETURN. По команде 


Смещение 

001 0001E0004F0009A 

615 220000000 

01Е 01 70111000B000004D7XXXXXX 

18 F800000 

IF F800000 
26 6005FXXXXXXX 
04F 01 С00 

118004 

10100F001 

11F18 

41F18 

21F18 

000B3701318 

101181F 

E4A 

37 C0126 7.7.1 

11F26 
21F26 
000C 
4A 0A 

Рис. 14.4. Внешний модуль XYZ. 


Комментарии 

Header indices 
CAS/lAS/SIS/FaiiltS 
Л (floating-point array 
В (integer) 

С (integerJ 

M (parameter integer) 

ACT О 

MOVE В ,4 

MOVE A,1 

MOVE C,B 

MULT C,B 


RETURN выполнение этого модуля завершается и управление 
передается вызывавшему его модулю. 

Полный текст модуля приведен на рис. 14.4. Модуль пред¬ 
ставлен не в виде единого кода по всей совокупности смежных 
токенов, а с выделением в строках отдельных ячеек и команд 
Таблица 14.2. Параметры программ для машин разного типа 


Машина 

Количество 

выполнен- 

Размер объ- 

дуля, байт 

Общий раз¬ 
мер про- 

ГР байт Ы ' 

Учебная ПЛ-машина 

62 

96 

369 

SYMBOL 

81 

324 

396 

Система 370 

1171) 

392 

5536 

SWARD 

14 

37 

77 


’) И еще ~90 000 команд в начале выполнения программы для выделения памяти 
подсистеме организации связи с подпрограммами. 
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для более наглядного рассмотрения. Первые две колонки не 
входят в структуру модуля. В них записаны порядковый номер 
первого токена соответствующей строки (от начала модуля) и 
порядковый номер первого токена строки в адресном простран¬ 
стве или области команд. В каждой строке имеется также текст 
комментария, не являющийся, конечно, частью модуля. 

TESTEST : PROCEDURE; 

DECLARE SIZE FIXED DECIMALS); 

DECLARE 1 B(7), 

2 N CHAR(8), 

2 T CHAR(2), 

2 A POINTER; 

DECLARE UNNAME CHAR(8) INIT('XXXXXXXX') 

CODE FIXED DECIMAL(l) INIT(9) 

DECURE NULL BUILTIN; 

В (1).N='ABCDEFGH 1 ; 

B(1).T='ER'; 

B(1).A=NULL; 

B(2).N='ABCDEFGH’; 

B(2).T='MD’; 

В (2).A=ADDR(UNNAME); 

SIZE=2; 

CALL MATCHES(B,UNNAME,CODE.SIZE); 

END; 


With PILLOW; use PILLOW; 
procedure TESTEST is 

SIZE : CURRENTENTRIES; 

В : MATCH_TABLE (INTEGER 1..7) 

UNNAME ; PROGNAME := "XXXXXXXX"; 

CODE : MATCHERROR := 9; 

begin 

В (1).NAME := "ABCDEFGH"; 

В (1).ETYPE := "ER"; 

B(l).ADDRESS := null ; 

В (2).NAME := "ABCDEFGH"; 

BC2).ETYPE ;= "MD"; ........ 

B(2).ADDRESS := UNNAME'ADDRESS; — Not Standard Ada 

SIZE ;= 2; 

MATCHES( В ,UNNAME,CODE.SIZE); 
end TESTEST; 


Рис. 14.5. Процедура 
TESTEST на языке 
ПЛ/1. 


Рис. 14.6. 
Процедѵоа 
TESTEST на 
языке Ада. 


В табл. 14.2 продолжено сопоставление параметров про¬ 
грамм: программы для учебной ПЛ-машины, эквивалентной ей 
программы на языке SPL для системы SYMBOL и рассматри¬ 
вавшейся в данной главе программы на языке ПЛ/1 для Систе¬ 
мы 370 и машины SWARD. 

В качестве еще одного примера рассмотрим программу, со¬ 
стоящую из двух раздельно компилируемых процедур 
(рис. 14.5—14.8). Программа написана на двух языках — Ада и 
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MATCHES: PROCEDURE(BODY,UNRESNAME,MATCHCODE,SIZE); 

DEC I.ARE 1 BODY(*) , 

2 NAME CHAR(8), 

2 TYPE CHAR(2), 

2 ADDRESS POINTER; 

DEC I,ARE 

MODULE CHAR(2) STATIC INIT('MD'), 

ENTRYPT CHAR(2) STATIC INIT('EP'), 

EXTREF CHAR(2) STATIC INITC'ER'); 

DECLARE NULL BUILTIN;' 

DECLARE MATCHCODE FIXED BINARY; 

DECLARE UNRESNAME CHAR(8); 

DECLARE SIZE FIXED BINARY; 

DECLARE 

I FIXED BINARY; 

J FIXED BINARY; 

MATCHCODE=2; 

IF (SIZE>0)&(SIZE-<>2000) 

THEN 

DO; 

MATCHCODE=0; 

DO 1=1 TO SIZE WHILE(MATCHCODE=0); 

IF BODY(I).ADDRESS=NULL 
THEN DO; 

MATCHCODE=l; 

DO J=1 TO SIZE WHILE(MATCHCODE=l); 

IF (BODY(I).NAME=BODY(Jj.NAME)& 

((BODY(J).TYPE=MODULE)| 

(BODY(J).TYPE=ENTRYPT)) 

THEN DO; 

MATCHCODE=0; 

BODY(I).ADDRESS=BODY(J).ADDRESS; 
END; 

ELSE; 

• END; 

IF MATCHCODE=l THEN UNRESNAME=BODY(I).NAME; 
ELSE; 


ELSE; 


END; 
END; 
ELSE; 
END; 


Рис. 14.7. Процедура MATCHES на языке ПЛ/1. 

ПЛ/1. Приведенный пример позволяет проиллюстрировать мно¬ 
гие возможности архитектуры: работу со строками символов» 
записями, массивами, указателями или переменными доступа» 
записями, компонентом которых является массив записей» 
а также оформление вызовов подпрограмм и работу с динами¬ 
ческой и статической частями адресного пространства. 

Внешний модуль для процедуры TESTEST представлен на 


23—283 
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, package PILLOW is 

type PROGNAME is STRING(1..8); 

type MATCHERROR is INTEGER range 0..2; 

type CURRENT_ENTRIES is INTEGER range 0..2000; 
type MATCH_TABLE_ENTRY is 

record 

NAME : PROGNAME; 

ETYPE : STRING (1..2); 

ADDRESS : access PROGNAME; 
end record ; 

type MATCHJTABLE is array (INTEGER range <>) of MATCH TABLE ENTRY; 
MODULE : constant 'STRING := "MD"; 

ENTRYPT ! constant STRING := "EP"; 

EXTREF : constant STRING := "ER"; 
procedure MATCHES 

(BODY ; in out MATCH_TABLE; 

UNRESNAME : out PROGNAME; 

j MATCHCODE : out MATCHERROR; 

SIZE ; in CURRENT ENTRIES); 

end PILLOW; 

I package body PILLOW is 
I procedure MATCHES 

(BODY : in out MATCHJTABLE; 

UNRESNAME : out PROGNAME; 

MATCHCODE : out MATCHERROR; 

SIZE : in CURRENT ENTRIES) is 

begin 

MATCHCODE := 2; 

if (SIZE>0) and (SIZE<=2000) then 
I MATCHCODE := 0; 

for I in 1..SIZE loop 

exit when MATCHCODE /= 0; ' 

if BODY(I).ADDRESS = null then 
MATCHCODE := 1; 
for J in 1..SIZE loop 

exit when MATCHCODE /= 1; 
if (BODY(I) .NAME = BODY(J) .NAME) and 
((BODY(J).ETYPE = MODULE) or 
(BODY(J).ETYPE = ENTRYPT)! then 
MATCHCODE := 0; 

BODY(I).ADDRESS = BODY(J).ADDRESS; 

end loop ; 

if MATCHCODE = 1 then 

UNRESNAME = BODY(I).NAME; 

end if ; 
end if ; 
end loop ; 
end if ; 

end MATCHES; 
end PILLOW; 

Рис. 14.8. Процедура MATCHES на языке Ада. 
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смещение Комментарии 

01 ООО1ЕООО7Ю00АВ0О12В Header 

15 330000000 CAS/IAS/SIS/FC 

IE 001 E40FOOOO SIZE 

009 702C10029000007801D0029 В (array of records) 


0000B008 
0010B002 
00149 
000000 

03B B008E7E7E7E7E7E7E7E7 
04F E1009 

71 054 9000000000000000 
000000 

06A B008C1C2C3C4 
C5C6C7C8 
07E B002C5D9 
086 B002D4C4 


' AB 001 COO 


ACT 


■ N (cf component) cdo=8 
B.T (cf component) cdo=10 
B.A (pointer comp) cdo=18 

UNNAME (character field) 
CODE 

MATCHES (pointer) 


'MD' 


1009000100806A MOVE B(l).N,'ABCDEFGH' 

1009000101007E MOVE B(1).T,'ER 1 

00010090001018 UNDEF В (1).A 

1009000200806A MOVE В (2).N,'ABCDEFGH’ 

10090002010086 MOVE B(2).T,'MD' 

0010009000201803B ССАР В (2 ) . A, UNN’AME 

10010002 MOVE SIZE,2 

D054043009000F CALL MATCHES,4,R/W(B),R/W(UNNAME), 
303B304F3001 R/W(C0DE),R/W(SIZE) 

OA RETURN 


Рис. 14.9. Внешний модуль TESTEST. 

рис. 14.9. Поскольку оба модуля по размерам не слишком ве¬ 
лики, оказалось возможным ограничиться адресами ячеек и ко¬ 
манд длиной 3 токен. В связи с тем что В является массивом 
записей или структур, он представлен ячейкой «массив», а его 
вложенный тег соответствует записи, содержащей три компо¬ 
нента. 

Модуль MATCHES, указатель и несколько констант разме¬ 
щены в статической части адресного пространства. Предпола¬ 
гается, что некоторая программа (например, редактор связей)' 
посредством команды LINK будет инициировать выполнение 
модуля MATCHES, пользуясь потенциальным адресом точки 
его входа. 

Структура получающегося кода достаточно очевидна. Опре¬ 
деленный интерес может представлять рассмотрение одной из 
команд MOVE как примера с адресами в виде записей. 

Исходному тексту MATCHES, представленному на рис. 14.7 
и 14.8, соответствует внешний модуль, приведенный на 
рис. 14.10. Коды внешнего модуля снабжены адресами и ком¬ 
ментариями. 


23* 
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Смещение 


Комментарии - 

001 

0001Е0008АОООА9001В4 Header 


015 

330000000 

CAS/IAS/SIS/Faults 

ОІЕ 001 

6030702С10000000000 BODY (parameter array of 


801D0029 . 

records) (D-bounded) 


0000B008 

BODY.NAME (cf component) cdo=8 


0010B002 

BODY.TYPE (cf component) cdo=10 


00149 

BODY.ADDRESS (cf component) cdo=18 


0000000 



, 038 

600SF00O0000 

MATCHCODE. (integer parameter) 

044 

6008B0080000000 

UNRESNAME (cf parameter) 

053 

6OO5FOOOO00O 

SIZE 

(integer parameter) 

05F 

F800000 

I 


066 

F800000 

J 


08А 06D 

B002D4C4 

MODULE 

(character field) 

075 

B002C5D7 

ENTRYPT (character field) 

07D 

B002C5D9 

EXTREF 

(character field) 

085 

F0007D0 

v '2000-' 


0А9 001 

C04001046038055 

ACT 

4, BODY,UNRESNAME, 




MATCHCODE,SIZE 


10380002 

MOVE 

MATCHCODE,2 


9053000010A 

GTBF 

SIZE,0,SH 


A05308510A . . 

LEBF 

SIZE, 2000, SH 


10380000 

MOVE 

MATCHCODE,0 


105F0001 

MOVE 

1,1 


A05F05310A 

LEBF 

I .SIZE,SH 

048 

7038000010A 

%A: EQBF 

MATCHCODE,0,SH 


000400105F018067 

DEFBF 

BODY(I).ADDRESS,SB 


E100 

В 

SG 

067 

10380001 

SB: MOVE 

MATCHCODE,1 


10660001 

MOVE 

J,1 


A0660530E8 

LEBF 

j,size,?;f 

081 

703800010E8 

SC: EQBF 

MATCHCODE,l.SF 


700105F008 

EQBF 

BODY(I).NAME, 


0010660080DE 


BODY ( J). NAME, ?1E 


600106600806D0C3 

NEBF 

BODY(J).NAME,MODULE,SD 


70010660080750DE 

EQBF 

BODY(J).NAME,ENTRYPT,SE 

ОСЗ 

10380000 

%D: MOVE 

MATCHCODE,0 


100105F018 

MOVE 

BODY(I).ADDRESS, 


001066018 


BODY(J).ADDRESS 

ODE 

5066053081 

%E: ITERATE 

J,SIZE,SC 

0Е8 

70380001100 

%F: EQBF 

MATCHCODE,1,SG 


104400105F008 

MOVE 

UNRESNAME,BODY(I).NAME 

100 

505F053048 

%G: ITERATE 

I,SIZE,%A 

10А 

OA 

%H: RETURN 



Рис. 14.10. Внешний модуль MATCHES. 
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ОТЛИЧИТЕЛЬНЫЕ ОСОБЕННОСТИ 
СИСТЕМЫ SWARD 

Основной отличительной особенностью, определенной уникаль¬ 
ностью архитектуры системы SWARD, является целенаправ¬ 
ленность всех ее средств на разрешение традиционных проблем 
программного обеспечения вычислительных систем. Главные 
пути достижения этой цели анализируются ниже. 

Рассматриваемая система осуществляет в значительной 
мере семантический контроль обрабатываемой информации, что 
должно способствовать значительному увеличению эффективно¬ 
сти процессов тестирования и отладки программ и ограничению 
последствий ошибок, допущенных на этапе создания рабочих 
программ. 

Вследствие того что архитектура SWARD основана на поня¬ 
тиях объектов и потенциальной адресации, оказывается воз¬ 
можным достичь высокой степени единообразия в решении во¬ 
просов программирования. Ко вісем объектам, входящим в ар¬ 
хитектуру (модулям, процесс-машинам, портам, памяти дан¬ 
ных), а также к устройствам ввода-вывода без памяти можно 
адресоваться аналогичным образом. Это позволяет существен¬ 
но упростить как системное программное обеспечение, так и 
программы пользователей. Например, традиционным системам 
присуще многообразие средств установления связи между раз¬ 
ными элементами. Так, для установления связи между про¬ 
граммными модулями используется редактор связи, для связи 
программ с файлами —операторы языка управления задания¬ 
ми и макрокоманды открытия этих файлов в программах, что же 
касается системы SWARD, то здесь достаточно ограничиться 
одним общим понятием «привязка». 

Положенный в основу системы SWARD принцип одноуровне¬ 
вой организации памяти может быть распространен и на струк¬ 
туру языков программирования, существенно сокращая потреб¬ 
ность в использовании традиционных принципов организации 
ввода-вывода. Все это упрощает работу программиста, позво¬ 
ляя ему использовать единый подход к проблемам манипулиро¬ 
вания данными. 

Возможность пользоваться одними и теми же командами 
SEND и RECEIVE как основными командами ввода-вывода для 
работы с внешними устройствами без памяти и как командами 
обмена данными между процессами дает много преимуществ. 
Во-первых, это тоже способствует более единообразному стилю 
работы программиста с системой, поскольку становится несу¬ 
щественным способ пересылки данных (например, строки сим- 




волов) — через порт на печатающее устройство, терминал или 
другому процессу. Таким образом, в системе достигается ис¬ 
пользование единого принципа передачи данных. Во-вторых, не 
внося изменений в программы, оказывается возможным заме¬ 
нять в операциях обмена внешние устройства на процессы и 
наоборот. В-третьих, работа системы передачи данных отлича¬ 
ется синхронностью выполнения операций записи и чтения как 
в случае обмена типа процесс — процесс, так и в случае обмена 
процесс — внешнее устройство. В соответствии с этим для си¬ 
стемы действительно только одно понятие параллельности вы¬ 
полнения операций — на уровне процессов. Понятие прерыва¬ 
ния в данном случае отсутствует 1 ). 

К другим единым принципам организации вычислительной 
системы SWARD, позволяющим упростить процесс программи¬ 
рования и достичь его большего соответствия возможностям ап¬ 
паратных средств системы, следует отнести введение специаль¬ 
ных средств обработки ошибок, потенциальной формы адреса¬ 
ции для совместного доступа к данным и для их защиты от 
несанкционированного доступа, системы команд, инвариантных 
к типу обрабатываемых данных, и отказ от привилегированного 
режима выполнения команд. 

Эффективная система вызова подпрограмм, разбиение адрес¬ 
ного пространства на небольшие области санкционированного 
доступа, средства обработки ошибок, одноуровневая память, 
использование команд GUARD, UNGUARD, SEND, RECEIVE 
и другие возможности системы благоприятствуют разработ¬ 
ке хорошо структурированных программ на основе прин¬ 
ципов . модульности, обеспечению защиты информации от 
несанкционированного доступа и распараллеливанию процес¬ 
сов. 

Все перечисленное выше касается программирования в це¬ 
лом, однако можно сделать ряд замечаний относительно орга- 


» Упоминаемые автором синхронность операций обмена и отсутствие 
прерывания (сравните со способом доступа с очередями в ОС ЕС) удобны 
для программиста лишь до тех пор, пока его устраивают временные харак¬ 
теристики передачи данных. В противном случае предпочтительнее перейти 
на несколько более трудоемкий метод разработки программ (например, ба¬ 
зисный способ доступа в ОС ЕС), чтобы, используя те же технические сред¬ 
ства— при обмене с внешними устройствами, физически построенном на 
асинхронизме и прерываниях,— обеспечить требуемые параметры функцио¬ 
нирования создаваемого программного обеспечения. 

Оценивая различные проявления униформизма в отношении объектов си¬ 
стемы или связей между ними, следует иметь в виду, что хотя такой подход 
обеспечивает простоту разработки и реализации программных средств воз¬ 
никают определенные противоречия с принципом эффективного использова¬ 
ния ресурсов системы. — Прим, перев. 
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«изации работы компиляторов, операционных систем и систем 
доступа к базам данных. Благодаря использованию теговой па¬ 
мяти, прямому распознаванию типов данных с многоуровневой 
организацией, таких, как массивы и структуры, мощной систе¬ 
ме команд, инвариантных к типу обрабатываемых данных, 
должны значительно снижаться затраты на разработку компи¬ 
ляторов и сложность последних. 

Данная архитектура позволяет исключить многие традици¬ 
онно сложные компоненты операционных и других управляю¬ 
щих систем, освобождая их от задач управления памятью, за¬ 
щиты данных, мониторных функций по синхронизации про¬ 
цессов, организации их связи по данным и обработки преры¬ 
ваний. 

Использование команд, инвариантных ,к типу обрабатывае¬ 
мых данных, и теговой памяти предполагает осуществление 
«привязки> команд и данных на самых поздних этапах подго¬ 
товки программы к выполнению. Конкретное функциональное 
назначение команды определяется к моменту ее выполнения 
посредством информации в тегах и ячейках операндов коман¬ 
ды. Это существенно для реализации работы различных систем 
управления базой данных в режиме независимости от типов 
данных. 

К недостаткам данной архитектуры можно отнести как оп¬ 
ределенные ограничения, так и трудности ее реализации. На¬ 
пример, некоторые числовые ограничения на включенные в 
теги параметры данных следовало бы сделать менее жесткими 
(увеличить допустимый размер строк символов). В системе 
неявно зафиксировано наименьшее допустимое значение индек¬ 
сов массивов, равное 1. Было бы желательно предоставить поль¬ 
зователю самому устанавливать эту величину. К недостаткам 
можно также отнести отсутствие в системе прямых средств для 
установки начальных значений элементов масоивов (см. упраж¬ 
нения в конце главы). 

Оказалось, что реализация отдельных принципов архитекту¬ 
ры либо слишком дорогостояща, либо практически неэффектив¬ 
на. То же самое можно заметить и в отношении принципа не¬ 
постоянного размера адресов ячеек и команд. Возникают труд¬ 
ности с реализацией операций десятичной арифметики с пла¬ 
вающей точкой. В отдельных случаях для достижения простоты 
реализации имеет смысл пожертвовать однородностью команд 
и их инвариантностью к типам обрабатываемых данных. В част¬ 
ности, является желательной возможность выполнять с по¬ 
мощью команды ADD (без необходимости дополнительного про¬ 
граммного преобразования данных) сложение десятичных чи¬ 
сел с фиксированной и плавающей точками или прибавление 
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скалярной величины ко всем элементам массива. Однако от 
выполнения с помощью подобных команд деления десятич¬ 
ных чисел с плавающей точкой одного массива на десятич¬ 
ные числа с фиксированной точкой другого массива можно от¬ 
казаться. 


ОКРУЖАЮЩАЯ СРЕДА 
СИСТЕМЫ 

Единственная существующая реализация архитектуры системы 
SWARD имеет так называемую горизонтальную структуру ми¬ 
кропрограммного уровня машины 1 ). Система функционирует на 
одном микропроцессоре, работающем в режиме разделения вре¬ 
мени между всеми активными процесс-машинами. Планируется 
подключение к системе еще нескольких процессоров. 

Чтобы дать общее представление о ресурсах, необходимых 
для построения системы, укажем, что микропрограмма для си¬ 
стемы SWARD занимает ~5000 52-битовых слов памяти. В дан¬ 
ной микропрограмме заложена возможность работы только с 
одним фиксированным значением длины адресов ячеек и команд 
(3 токен), не предусмотрена возможность работы с расширен¬ 
ным множеством команд и не обеспечиваются операции деся¬ 
тичной арифметики с плавающей точкой. По сравнению с дру¬ 
гими командами большая часть микропрограмм приходится на 
команды MOVE (поскольку ее операндами могут быть ячейки 
любого типа, причем сложной структуры), CREATE-MODULE 
и DESTROY. Сложнее всего оказалась часть программы, реали¬ 
зующая команду DESTROY. Приходится учитывать, например, 
что уничтожение объекта «процесс-машина» может неявно по¬ 
влечь за собой необходимость уничтожения ряда других объек¬ 
тов, в том числе и других процесс-машин. 

Исходным языком программирования, поддерживаемым про¬ 
граммным обеспечением в SWARD, является язык Soada — 
расширенная версия языка Ада. Необходимость модификации 
вызвана тем, что его структура не в полной мере соответствует 
принципам системы SWARD. Язык Ада разрабатывался специ¬ 
ально для систем с традиционной архитектурой, для которой 
характерно установление всех связей между программными 
элементами выполняемого задания на ранних стадиях его обра¬ 
ботки системой — на этапе компилирования. Что касается си¬ 
стемы SWARD, то она почти по всем показателям может быть 


*> Представление об определении горизонтальной структуры микропро¬ 
граммного уровня и ее отличии от вертикальной структуры читатель может 
получить из книги Таненбаум Э., Многоуровневая организация ЭВМ. Пер. 
с англ. М.: Мир, 1979, с. 232—236 . — Прим. ред. 



СИСТЕМА SWARD 361 


охарактеризована как вычислительная среда с «отсрочкой» 
установления связей до самых последних стадий. По сравне¬ 
нию с языком Ада в языке Soada предусмотрено 

1) использование переменных с инвариантными атрибутами 
доступа (динамически определяемым типом) и формальных 
параметров; 

2) возможность включения кодов доступа в переменные до¬ 
ступа; 

3) возможность рассмотрения пакетов и подпрограмм как 
объектов; 

4) использование строк переменной длины; 

5) обработка признаков типа на этапе выполнения. 

Последняя возможность иллюстрируется следующими фраг¬ 
ментами операторов на языке Soada: 

if X. all’OSTYPE = PACKAGE... 

if A’VTYPE = INTEGER or A’VTYPE = COLOR... 

Операционная система машины SWARD отличается тем, 
что лишь в незначительной степени занята выполнением функ¬ 
ций традиционных операционных систем (управления процес¬ 
сами, памятью, обеспечением режима разделения времени меж¬ 
ду процессами и т. п.), так как эти функции заложены в основу 
машины SWARD. Согласно принципам архитектуры системы 
SWARD, операционную систему можно рассматривать как па¬ 
кет прикладных программ, обеспечивающих при необходимости 
выполнение определенных функций обслуживания (прикладные 
программы не поддерживают непосредственной связи о опера¬ 
ционной системой). Большая часть таких функций связана с 
управлением справочниками, в частности согласование системы 
потенциальной адресации іс системой вводимых пользователем 
имен и кодов доступа. 

К основному процессору системы SWARD подключено не¬ 
сколько микропроцессоров, функционирующих в основном в 
роли каналов ввода-вывода. Предусмотрено, что, если при вы¬ 
полнении программ встретятся команды SEND или RECEIVE 
с не определенным в системе потенциальным адресом, система 
SWARD не регистрирует тотчас же «ошибку», а пересылает эту 
команду в микропроцессоры. Если этот потенциальный адрес 
может быть распознан микропроцессорами (например, как соот¬ 
ветствующий некоторому терминалу), они и выполняют указан¬ 
ную команду. Отдельные программы в микропроцессорах так¬ 
же наделены потенциальными адресами системы. Это позволя¬ 
ет любой программе системы взаимодействовать с ними на ос¬ 
нове предусмотренного механизма записи и чтения. В частности, 
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реализованная система SWARD подсоединена к Системе 370. 
Если в команде RECEIVE установить необходимый потенци¬ 
альный адрес, то посредством программ микропроцессора 
оказывается возможным получить нужный файл из Систе¬ 
мы 370. 

Возможность обращения к терминалам через потенциальные 
адреса как к отдельным объектам однородного множества объ¬ 
ектов системы позволяет выйти за пределы традиционных жест¬ 
ких режимов работы, когда устанавливается строгая однознач¬ 
ная связь между пользователями терминалов и процессами. 
Пользователь за терминалом теперь может инициировать вы¬ 
полнение множества процессов и в то же время продолжать 
взаимодействие о операционной системой на языке ее команд. 
Процесс же может выполнять обмен со многими терминалами, 
как только ему окажутся доступными соответствующие потен¬ 
циальные адреса. 


УПРАЖНЕНИЯ 

14.1. Каковы атрибуты и значение содержимого ячейки, представленной 
кодом D410237493? 

14.2. Для каких целей используются ячейки «строка токенов» и «поле то¬ 
кенов»? 

14.3. Почему с помощью ячеек «косвенный доступ к данным» и «пара¬ 
метр» с динамически определённым типом не могут адресоваться массивы и 
записи? Почему с помощью указанных ячеек нельзя обращаться также к 
ячейкам, тип которых определяется пользователем? 

14.4. Допустим, что первая команда MOVE в программе на рис. 14.9 
должна быть изменена таким образом, чтобы последовательность символов 
ABCDEFGH была помещена во все элементы B.N. 1 '. Как будет в этом случае 
выглядеть машинная команда? 

14.5. Для программы, изображенной на рис. 14.9, составьте машинную 
команду, обеспечивающую пересылку второго элемента массива В в первый 
элемент этого же массива. 

14.6. Каким образом компилятор может обеспечить присвоение началь¬ 
ных значений элементам массива? 

14.7. Какое представление в архитектуре системы SWARD получают гло¬ 
бальные данные (например, переменные с атрибутом EXTERNAL языка 


') То есть в первые компоненты всех записей, являющихся элемента¬ 
ми В. — Прим, перев. 
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ПЛ/1, переменные области COMMON языка ФОРТРАН, переменные в опи¬ 
сании пакета языка Ада) ? 

14.8. В каких случаях компилятор генерирует команду UNDEFINE? 

14.9. Положив CAS=IAS=3, скомпилируйте, пользуясь карандашом и 
бумагой, для системы SWARD следующий модуль, написанный на языке 
Ада: 


package SAMPLE is 

QUASI : array (INTEGER 1..10) of INTEGER; 

MICH : array (INTEGER 1..10) of STRING (1..8)} 
end SAMPLE; 

package body SAMPLE is 
procedure SAMSTORE 


(Q : 
M : 
N ; 


INTEGER; 
STRING; 
INTEGER) is 


begin 

if QUASI (N) = 0 then 
QUASI (N) := Q;- 

У, MICH (N) (Q.. Q+M' LENGTH -1) :=. M; 

— store.string M beginning at Qth position 


else 

BUFFALO(MICH(N)); 

end if ; 

end SAMSTORE; 

procedure SAMSTOP (Q s in INTEGER) is 

begin 

for I in 1..10 loop 

QUASI (I) := QUASI (I) + I.-V Q; 
end loop ; 
end SAMSTOP; 
end SAMPLE; 


in MICH(N) 


14.10. Укажите, какие улучшения могут быть внесены в текст предыду¬ 
щей программы оптимизирующим компилятором. 

14.11. Предложите несколько типов команд, которые целесообразно вклю¬ 
чить в расширенное множество команд для языков КОБОЛ, ФОРТРАН, 
ПЛ/1, Паскаль и Ада. Не понадобятся ли для этого дополнительные типы 
ячеек? 
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МЕТОДЫ АВТОМАТИЧЕСКОГО РАСПОЗНАВА¬ 
НИЯ РЕЧИ: В 2-х книгах. Пер. с англ./Под ред. 
У. Ли. Кн. 1, 23, 98 л., цена 3 р. 40 к. Кн. 2, 27, 49 л., 
цена 3 р. 80 к. 

В книге 1 рассмотрены акустические и фонетиче¬ 
ские методы распознавания речи, применяемые в на¬ 
стоящее время при автоматическом вводе речевой ин¬ 
формации в автоматизированных системах проектиро¬ 
вания, конструирования, технологической подготовки 
производства и управления производственными про¬ 
цессами. Большое внимание уделяется коррекции 
ошибок при распознавании речи разными методами 
и нахождению оптимальных способов определения 
правильности вводимых в ЭВМ слов, а также управ¬ 
ляющим структурам для построения различных си¬ 
стем распознавания. 

Предназначена для системотехников, инженеров- 
математиков и филологов, занимающихся автомати¬ 
зацией проектирования и конструирования. 
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в 1984 году 
выпустило книгу 


Р. ИЗЕРМАН. Цифровые системы управления. 

Пер. с англ., 31,60 л., цена 2 р. 50 к. 

В труде специалиста из ФРГ рассмотрены со¬ 
временные методы расчета и проектирования цифро¬ 
вых систем управления с детерминированными и слу¬ 
чайными возмущениями. Значительное внимание уде¬ 
лено теории многосвязных и адаптивных систем 
управления. 

Для специалистов в области автоматического 
управления и вычислительной техники, а также аспи¬ 
рантов и студентов соответствующих специальностей. 



ИЗДАТЕЛЬСТВО «МИР» 
в 1984 году 
выпустило книгу 


В. Ф Р И Т Ч. Применение микропроцессоров в си¬ 
стемах управления. Пер. с нем., 28,99 л., цена 

2 р. 30 к. 

В книге известного ученого из ГДР рассматрива¬ 
ются принципы построения и структурные схемы при¬ 
менения микропроцессоров в системах автоматиче¬ 
ского управления производственными процессами. 
Много внимания уделено вопросам стыковки микро¬ 
процессоров с регуляторами или системами, обеспе¬ 
чения надлежащего качества протекания процессов и 
создания наиболее экономичных структур. 

Для специалистов в области автоматики и вычи¬ 
слительной техники, а также студентов старших кур¬ 
сов соответствующих специальностей вузов. 


















